Elektronische Gesundheitskarte und Telematikinfrastruktur




Spezifikation

Konnektor



    
Version 5.18.0
Revision 571788
Stand 28.11.2022
Status freigegeben
Klassifizierung öffentlich
Referenzierung gemSpec_Kon

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Version
Stand
Kap./ Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
5.1.0
05.10.17

Initialversion Online-Produktivbetrieb (Stufe 2.1)
gematik
5.2.0
18.12.17

Einarbeitung Erratas 1.6.4-1 bis 1.6.4-3, P15.1
gematik
5.3.0
14.05.18

Einarbeitung P15.2, P15.4 und P15.5
gematik
5.4.0
26.10.18

Einarbeitung P15.8 und P15.9
gematik
5.5.0
18.12.18

Einarbeitung P17.1
gematik
5.6.0 15.05.19
Einarbeitung P18.1
gematik
5.7.0 28.06.19
Einarbeitung P19.1
gematik
5.8.0 02.10.19 Einarbeitung P20.1/2 gematik
5.9.0 02.03.20 Einarbeitung P21.1 gematik
5.9.1 26.06.20 Einarbeitung P21.3 gematik
5.9.2 27.08.20 Einarbeitung P21.4 gematik
5.9.3 21.09.20 Einarbeitung P21.5 gematik
5.9.4 05.11.20 Einarbeitung P21.6 gematik
5.10.0 30.06.20 Einarbeitung P22.1 gematik
5.11.0 12.11.20 Einarbeitung Scope-Themen zu R4.0.1 gematik
5.12.0 09.12.20 Einarbeitung P22.5 gematik
5.13.0 30.06.21 Einarbeitung Konn_Maintenance_21.1, _21.2, _21.3 und gemF_gSMC-K_Laufzeitverlängerung gematik
5.14.0 02.09.21 Umbenennung der Begriffe "aAdG-NetG" in "WANDA Basic", "aAdG" und "aAdG-NetG-TI" in"WANDA Smart"
gematik
5.15.0 31.01.22 Einarbeitung Konn_Maintenance_21.6, Einarbeitung CI_Maintenance_21.2: Ergänzung der Tabelle 3 im Kap. 4.2.1.1.1 um "WANDA Basic"  gematik
5.16.0 02.05.22 Einarbeitung Konn_Maintenance_22.1 (mit Ausbau der Änderungen aus gemF_gSMC-K_Laufzeitverlängerung) gematik
5.17.0 30.06.22 Einarbeitung Konn_Maintenance_22.3 gematik
5.18.0 28.11.22 Einarbeitung Konn_Maintenance_22.4, _22.5, _22.6, redaktionell: diskriminierungsfreie Sprache (Black-/Whitelist in Deny-/Allowlist) gematik

Inhaltsverzeichnis

  • Dokumentinformationen
  • Inhaltsverzeichnis
  • : 1 Einordnung des Dokumentes
  • : : 1.1 Zielsetzung
  • : : 1.2 Zielgruppe
  • : : 1.3 Geltungsbereich
  • : : 1.4 Abgrenzung des Dokuments
  • : : 1.5 Methodik
  • : : : 1.5.1 Anforderungen
  • : : : 1.5.2 Offene Punkte
  • : : : 1.5.3 Erläuterungen zur Spezifikation des Außenverhaltens
  • : : : 1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“
  • : : : : 1.5.4.1 Modulare Spezifikation über Funktionsmerkmale
  • : : : : 1.5.4.2 Technische Use Cases - TUCs
  • : : : : 1.5.4.3 Event-Mechanismus
  • : : : : 1.5.4.4 Konfigurationsparameter und Zustandswerte
  • : 2 Systemüberblick
  • : : 2.1 Logische Struktur
  • : : 2.2 Sicherer Datenspeicher
  • : : 2.3 Überblick Konnektoridentität
  • : : 2.4 Mandantenfähigkeit
  • : : 2.5 Versionierung
  • : : 2.6 Fachanwendungen
  • : : 2.7 Netzseitige Einsatzszenarien
  • : : : 2.7.1 Parameter ANLW_ANBINDUNGS_MODUS
  • : : : 2.7.2 Parameter ANLW_INTERNET_MODUS
  • : : 2.8 Lokale und entfernte Kartenterminals
  • : : 2.9 Standalone-Szenario
  • : 3 Übergreifende Festlegungen
  • : : 3.1 Allgemeine übergreifende Festlegungen
  • : : : 3.1.1 Dokumentformate
  • : : : 3.1.2 Kartentypen
  • : : : 3.1.3 Übergreifende Festlegungen zum Aufbau von sicheren Verbindungen
  • : : 3.2 Konnektoridentität und gSMC-K
  • : : : 3.2.1 Organisatorische Anforderungen und Sperrprozesse
  • : : 3.3 Bootup-Phase
  • : : 3.4 Betriebszustand
  • : : : 3.4.1 Betriebsaspekte
  • : : 3.5 Fachliche Anbindung der Clientsysteme
  • : : : 3.5.1 Betriebsaspekte
  • : : 3.6 Clientsystemschnittstelle
  • : : : 3.6.1 SOAP-Schnittstelle
  • : : : 3.6.2 Statusrückmeldung und Fehlerbehandlung
  • : : : 3.6.3 Transport großer Dokumente
  • : : 3.7 Verwendung manuell importierter CA-Zertifikate
  • : : 3.8 Testunterstützung
  • : 4 Funktionsmerkmale
  • : : 4.1 Anwendungskonnektor
  • : : : 4.1.1 Zugriffsberechtigungsdienst
  • : : : : 4.1.1.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.1.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.1.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.1.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.1.4.1 TUC_KON_000 „Prüfe Zugriffsberechtigung“
  • : : : : 4.1.1.5 Operationen an der Außenschnittstelle
  • : : : : 4.1.1.6 Betriebsaspekte
  • : : : 4.1.2 Dokumentvalidierungsdienst
  • : : : : 4.1.2.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.2.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.2.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.2.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.2.4.1 TUC_KON_080 „Dokument validieren”
  • : : : : 4.1.2.5 Operationen an der Außenschnittstelle
  • : : : : 4.1.2.6 Betriebsaspekte
  • : : : 4.1.3 Dienstverzeichnisdienst
  • : : : : 4.1.3.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.3.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.3.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.3.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.3.4.1 TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“
  • : : : : 4.1.3.5 Operationen an der Außenschnittstelle
  • : : : : 4.1.3.6 Betriebsaspekte
  • : : : 4.1.4 Kartenterminaldienst
  • : : : : 4.1.4.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.4.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.4.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.1.4.3.1 TUC_KON_050 „Beginne Kartenterminalsitzung“
  • : : : : : 4.1.4.3.2 TUC_KON_054 „Kartenterminal hinzufügen“
  • : : : : : 4.1.4.3.3 TUC_KON_053 „Paire Kartenterminal“
  • : : : : : 4.1.4.3.4 TUC_KON_055 „Befülle CT-Object“
  • : : : : 4.1.4.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.4.4.1 TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“
  • : : : : : 4.1.4.4.2 TUC_KON_056 „Karte anfordern“
  • : : : : : 4.1.4.4.3 TUC_KON_057 „Karte auswerfen“
  • : : : : : 4.1.4.4.4 TUC_KON_058 „Displaygröße ermitteln“
  • : : : : 4.1.4.5 Operationen an der Außenschnittstelle
  • : : : : : 4.1.4.5.1 RequestCard
  • : : : : : 4.1.4.5.2 EjectCard
  • : : : : 4.1.4.6 Betriebsaspekte
  • : : : : : 4.1.4.6.1 Allgemeine Betriebsaspekte
  • : : : : : 4.1.4.6.2 Kartenterminals pflegen
  • : : : : : 4.1.4.6.3 Import der Kartenterminal-Informationen
  • : : : 4.1.5 Kartendienst
  • : : : : 4.1.5.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.5.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.5.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.1.5.3.1 TUC_KON_001 „Karte öffnen“
  • : : : : 4.1.5.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.5.4.1 TUC_KON_026 „Liefere CardSession“
  • : : : : : 4.1.5.4.2 TUC_KON_012 „PIN verifizieren“
  • : : : : : 4.1.5.4.3 TUC_KON_019 „PIN ändern“
  • : : : : : 4.1.5.4.4 TUC_KON_021 „PIN entsperren“
  • : : : : : 4.1.5.4.5 TUC_KON_022 „Liefere PIN-Status“
  • : : : : : 4.1.5.4.6 TUC_KON_027 „PIN-Schutz ein-/ausschalten“
  • : : : : : 4.1.5.4.7 TUC_KON_023 „Karte reservieren“
  • : : : : : 4.1.5.4.8 TUC_KON_005 „Card-to-Card authentisieren“
  • : : : : : 4.1.5.4.9 TUC_KON_202 „LeseDatei“
  • : : : : : 4.1.5.4.10 TUC_KON_203 „SchreibeDatei“
  • : : : : : 4.1.5.4.11 TUC_KON_204 „LöscheDateiInhalt“
  • : : : : : 4.1.5.4.12 TUC_KON_209 „LeseRecord“
  • : : : : : 4.1.5.4.13 TUC_KON_210 „SchreibeRecord“
  • : : : : : 4.1.5.4.14 TUC_KON_211 „LöscheRecordInhalt“
  • : : : : : 4.1.5.4.15 TUC_KON_214 „FügeHinzuRecord“
  • : : : : : 4.1.5.4.16 TUC_KON_215 „SucheRecord“
  • : : : : : 4.1.5.4.17 TUC_KON_018 „eGK-Sperrung prüfen“
  • : : : : : 4.1.5.4.18 TUC_KON_006 „Datenzugriffsaudit eGK schreiben“
  • : : : : : 4.1.5.4.19 TUC_KON_218 „Signiere“
  • : : : : : 4.1.5.4.20 TUC_KON_219 „Entschlüssele“
  • : : : : : 4.1.5.4.21 TUC_KON_200 „SendeAPDU“
  • : : : : : 4.1.5.4.22 TUC_KON_024 „Karte zurücksetzen“
  • : : : : : 4.1.5.4.23 TUC_KON_216 „LeseZertifikat“
  • : : : : : 4.1.5.4.24 TUC_KON_036 „LiefereFachlicheRolle“
  • : : : : 4.1.5.5 Operationen an der Außenschnittstelle
  • : : : : : 4.1.5.5.1 VerifyPin
  • : : : : : 4.1.5.5.2 ChangePin
  • : : : : : 4.1.5.5.3 GetPinStatus
  • : : : : : 4.1.5.5.4 UnblockPin
  • : : : : : 4.1.5.5.5 EnablePin
  • : : : : : 4.1.5.5.6 DisablePin
  • : : : : 4.1.5.6 Betriebsaspekte
  • : : : : : 4.1.5.6.1 TUC_KON_025 "Initialisierung Kartendienst"
  • : : : : : 4.1.5.6.2 Kartenübersicht und PIN-Management
  • : : : 4.1.6 Systeminformationsdienst
  • : : : : 4.1.6.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.6.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.6.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.6.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.6.4.1 TUC_KON_256 „Systemereignis absetzen“
  • : : : : : 4.1.6.4.2 TUC_KON_252 „Liefere KT_Liste“
  • : : : : : 4.1.6.4.3 TUC_KON_253 „Liefere Karten_Liste“
  • : : : : : 4.1.6.4.4 TUC_KON_254 „Liefere Ressourcendetails“
  • : : : : 4.1.6.5 Operationen an der Außenschnittstelle
  • : : : : : 4.1.6.5.1 GetCardTerminals
  • : : : : : 4.1.6.5.2 GetCards
  • : : : : : 4.1.6.5.3 GetResourceInformation
  • : : : : : 4.1.6.5.4 Subscribe
  • : : : : : 4.1.6.5.5 Unsubscribe
  • : : : : : 4.1.6.5.6 RenewSubscriptions
  • : : : : : 4.1.6.5.7 GetSubscription
  • : : : : 4.1.6.6 Betriebsaspekte
  • : : : 4.1.7 Verschlüsselungsdienst
  • : : : : 4.1.7.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.7.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.7.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.7.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.7.4.1 TUC_KON_070 „Daten hybrid verschlüsseln”
  • : : : : : 4.1.7.4.2 TUC_KON_071 „Daten hybrid entschlüsseln”
  • : : : : : 4.1.7.4.3 TUC_KON_072 „Daten symmetrisch verschlüsseln”
  • : : : : : 4.1.7.4.4 TUC_KON_073 „Daten symmetrisch entschlüsseln”
  • : : : : : 4.1.7.4.5 TUC_KON_075 „Symmetrisch verschlüsseln“
  • : : : : : 4.1.7.4.6 TUC_KON_076 „Symmetrisch entschlüsseln“
  • : : : : 4.1.7.5 Operationen an der Außenschnittstelle
  • : : : : : 4.1.7.5.1 EncryptDocument
  • : : : : : 4.1.7.5.2 DecryptDocument
  • : : : : 4.1.7.6 Betriebsaspekte
  • : : : 4.1.8 Signaturdienst
  • : : : : 4.1.8.1 Funktionsmerkmalweite Aspekte
  • : : : : : 4.1.8.1.1 Dokumentensignatur
  • : : : : : 4.1.8.1.2 Signaturrichtlinien
  • : : : : : 4.1.8.1.3 Signaturzeitpunkt
  • : : : : : 4.1.8.1.4 Jobnummer
  • : : : : : 4.1.8.1.5 Komfortsignatur
  • : : : : 4.1.8.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.8.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.1.8.3.1 TUC_KON_155 „Dokumente zur Signatur vorbereiten”
  • : : : : : 4.1.8.3.2 TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
  • : : : : : 4.1.8.3.3 TUC_KON_166 „nonQES Signaturen erstellen“
  • : : : : : 4.1.8.3.4 TUC_KON_152 "Signaturvoraussetzungen für QES prüfen"
  • : : : : : 4.1.8.3.5 TUC_KON_154 "QES Signaturen erstellen"
  • : : : : : 4.1.8.3.6 TUC_KON_168 „Einzelsignatur QES erstellen“
  • : : : : : 4.1.8.3.7 TUC_KON_158 "Komfortsignaturen erstellen"
  • : : : : 4.1.8.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.8.4.1 TUC_KON_160 „Dokumente nonQES signieren”
  • : : : : : 4.1.8.4.2 TUC_KON_161 „nonQES Dokumentsignatur prüfen”
  • : : : : : 4.1.8.4.3 TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur”
  • : : : : : 4.1.8.4.4 TUC_KON_150 „Dokumente QES signieren”
  • : : : : : 4.1.8.4.5 Anforderungen an die Stapelsignatur
  • : : : : : 4.1.8.4.6 TUC_KON_151 „QES Dokumentensignatur prüfen“
  • : : : : : 4.1.8.4.7 TUC_KON_170 „Dokumente mit Komfort signieren”
  • : : : : : 4.1.8.4.8 TUC_KON_171 „Komfortsignatur einschalten”
  • : : : : : 4.1.8.4.9 TUC_KON_172 „Komfortsignatur ausschalten”
  • : : : : : 4.1.8.4.10 TUC_KON_173 „Liefere Signaturmodus”
  • : : : : 4.1.8.5 Operationen an der Außenschnittstelle
  • : : : : : 4.1.8.5.1 SignDocument (nonQES und QES)
  • : : : : : 4.1.8.5.2 VerifyDocument (nonQES und QES)
  • : : : : : 4.1.8.5.3 StopSignature
  • : : : : : 4.1.8.5.4 GetJobNumber
  • : : : : : 4.1.8.5.5 ActivateComfortSignature
  • : : : : : 4.1.8.5.6 DeactivateComfortSignature
  • : : : : : 4.1.8.5.7 GetSignatureMode
  • : : : : 4.1.8.6 Betriebsaspekte
  • : : : 4.1.9 Zertifikatsdienst
  • : : : : 4.1.9.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.9.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.9.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.1.9.3.1 TUC_KON_032 „TSL aktualisieren“
  • : : : : : 4.1.9.3.2 TUC_KON_031 „BNetzA-VL aktualisieren“
  • : : : : : 4.1.9.3.3 TUC_KON_040 „CRL aktualisieren“
  • : : : : : 4.1.9.3.4 TUC_KON_033 „Zertifikatsablauf prüfen“
  • : : : : 4.1.9.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.9.4.1 TUC_KON_037 „Zertifikat prüfen"
  • : : : : : 4.1.9.4.2 TUC_KON_042 „CV-Zertifikat prüfen“
  • : : : : : 4.1.9.4.3 TUC_KON_034 „Zertifikatsinformationen extrahieren“
  • : : : : 4.1.9.5 Operationen an der Außenschnittstelle
  • : : : : : 4.1.9.5.1 CheckCertificateExpiration
  • : : : : : 4.1.9.5.2 ReadCardCertificate
  • : : : : : 4.1.9.5.3 VerifyCertificate
  • : : : : 4.1.9.6 Betriebsaspekte
  • : : : : : 4.1.9.6.1 TUC_KON_035 „Zertifikatsdienst initialisieren“
  • : : : 4.1.10 Protokollierungsdienst
  • : : : : 4.1.10.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.10.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.10.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.10.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.10.4.1 TUC_KON_271 „Schreibe Protokolleintrag“
  • : : : : 4.1.10.5 Operationen an der Außenschnittstelle
  • : : : : 4.1.10.6 Betriebsaspekte
  • : : : : : 4.1.10.6.1 TUC_KON_272 „Initialisierung Protokollierungsdienst
  • : : : 4.1.11 TLS-Dienst
  • : : : : 4.1.11.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.11.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.11.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.11.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.11.4.1 TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
  • : : : : : 4.1.11.4.2 TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
  • : : : : 4.1.11.5 Operationen an der Außenschnittstelle
  • : : : : 4.1.11.6 Betriebsaspekte
  • : : : 4.1.12 LDAP-Proxy
  • : : : : 4.1.12.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.1.12.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.12.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.1.12.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.1.12.4.1 TUC_KON_290 „LDAP-Verbindung aufbauen“
  • : : : : : 4.1.12.4.2 TUC_KON_291 „Verzeichnis abfragen“
  • : : : : : 4.1.12.4.3 TUC_KON_292 „LDAP-Verbindung trennen"
  • : : : : : 4.1.12.4.4 TUC_KON_293 „Verzeichnisabfrage abbrechen"
  • : : : : 4.1.12.5 Operationen an der Außenschnittstelle
  • : : : : : 4.1.12.5.1 Unterstützte LDAPv3 Operationen
  • : : : : 4.1.12.6 Betriebsaspekte
  • : : : 4.1.13 Authentifizierungsdienst
  • : : : : 4.1.13.1 Funktionsmerkmalweite Aspekte
  • : : : : : 4.1.13.1.1 Externe Authentisierung
  • : : : : 4.1.13.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.1.13.3 Interne TUCs
  • : : : : 4.1.13.4 Operationen an der Außenschnittstelle
  • : : : : : 4.1.13.4.1 ExternalAuthenticate
  • : : : : 4.1.13.5 Betriebsaspekte
  • : : : 4.1.14 Betriebsdatenmeldedienst
  • : : 4.2 Netzkonnektor
  • : : : 4.2.1 Anbindung LAN/WAN
  • : : : : 4.2.1.1 Funktionsmerkmalweite Aspekte
  • : : : : : 4.2.1.1.1 Netzwerksegmentierung
  • : : : : : 4.2.1.1.2 Routing und Firewall
  • : : : : 4.2.1.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.2.1.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.2.1.3.1 TUC_KON_305 „LAN-Adapter initialisieren“
  • : : : : : 4.2.1.3.2 TUC_KON_306 „WAN-Adapter initialisieren“
  • : : : : : 4.2.1.3.3 TUC_KON_304 „Netzwerk-Routen einrichten“
  • : : : : 4.2.1.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : 4.2.1.5 Operationen an der Außenschnittstelle
  • : : : : 4.2.1.6 Betriebsaspekte
  • : : : 4.2.2 DHCP-Server
  • : : : : 4.2.2.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.2.2.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.2.2.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.2.2.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : 4.2.2.5 Operationen an der Außenschnittstelle
  • : : : : : 4.2.2.5.1 Liefere Netzwerkinformationen über DHCP
  • : : : : 4.2.2.6 Betriebsaspekte
  • : : : : : 4.2.2.6.1 TUC_KON_343 „Initialisierung DHCP-Server“
  • : : : 4.2.3 DHCP-Client
  • : : : : 4.2.3.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.2.3.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.2.3.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.2.3.3.1 TUC_KON_341 „DHCP-Informationen beziehen“
  • : : : : 4.2.3.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : 4.2.3.5 Operationen an der Außenschnittstelle
  • : : : : 4.2.3.6 Betriebsaspekte
  • : : : 4.2.4 VPN-Client
  • : : : : 4.2.4.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.2.4.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.2.4.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.2.4.3.1 TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
  • : : : : : 4.2.4.3.2 TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“
  • : : : : 4.2.4.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : 4.2.4.5 Operationen an der Außenschnittstelle
  • : : : : 4.2.4.6 Betriebsaspekte
  • : : : 4.2.5 Zeitdienst
  • : : : : 4.2.5.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.2.5.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.2.5.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.2.5.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.2.5.4.1 TUC_KON_351 “Liefere Systemzeit”
  • : : : : 4.2.5.5 Operationen an der Außenschnittstelle
  • : : : : : 4.2.5.5.1 Sync_Time
  • : : : : 4.2.5.6 Betriebsaspekte
  • : : : : : 4.2.5.6.1 TUC_KON_352 Initialisierung Zeitdienst
  • : : : 4.2.6 Namensdienst und Dienstlokalisierung
  • : : : : 4.2.6.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.2.6.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.2.6.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : 4.2.6.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.2.6.4.1 TUC_KON_361 „DNS-Namen auflösen“
  • : : : : : 4.2.6.4.2 TUC_KON_362 „Liste der Dienste abrufen“
  • : : : : : 4.2.6.4.3 TUC_KON_363 „Dienstdetails abrufen“
  • : : : : 4.2.6.5 Operationen an der Außenschnittstelle
  • : : : : : 4.2.6.5.1 GetIPAddress
  • : : : : 4.2.6.6 Betriebsaspekte
  • : : : 4.2.7 Optionale Verwendung von IPv6
  • : : 4.3 Konnektormanagement
  • : : : 4.3.1 Zugang und Benutzerverwaltung des Konnektormanagements
  • : : : 4.3.2 Konnektorname und Versionsinformationen
  • : : : 4.3.3 Konfigurationsdaten: Persistieren sowie Export-Import
  • : : : 4.3.4 Administration von Fachmodulen
  • : : : 4.3.5 Neustart und Werksreset
  • : : : 4.3.6 Leistungsumfänge und Standalone-Szenarios
  • : : : 4.3.7 Online-Anbindung verwalten
  • : : : 4.3.8 Re-Registrierung des Konnektors mit weiterem NK-Zertifikat
  • : : : 4.3.9 Remote Management (Optional)
  • : : : 4.3.10 Software- und Konfigurationsaktualisierung (KSR-Client)
  • : : : : 4.3.10.1 Funktionsmerkmalweite Aspekte
  • : : : : 4.3.10.2 Durch Ereignisse ausgelöste Reaktionen
  • : : : : 4.3.10.3 Interne TUCs, nicht durch Fachmodule nutzbar
  • : : : : : 4.3.10.3.1 TUC_KON_280 „Konnektoraktualisierung durchführen“
  • : : : : : 4.3.10.3.2 TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
  • : : : : : 4.3.10.3.3 TUC_KON_282 „UpdateInformationen beziehen“
  • : : : : : 4.3.10.3.4 TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
  • : : : : 4.3.10.4 Interne TUCs, auch durch Fachmodule nutzbar
  • : : : : : 4.3.10.4.1 TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
  • : : : : : 4.3.10.4.2 TUC_KON_286 „Paket für Fachmodul laden“
  • : : : : 4.3.10.5 Operationen an der Außenschnittstelle
  • : : : : 4.3.10.6 Betriebsaspekte
  • : : : : : 4.3.10.6.1 TUC_KON_284 KSR-Client initialisieren
  • : : : 4.3.11 Konnektorstatus
  • : : 4.4 Hardware-Merkmale des Konnektors
  • : 5 Anhang A – Verzeichnisse
  • : : 5.1 Abkürzungen
  • : : 5.2 Glossar
  • : : 5.3 Abbildungsverzeichnis
  • : : 5.4 Tabellenverzeichnis
  • : : 5.5 Referenzierte Dokumente
  • : : : 5.5.1 Dokumente der gematik
  • : : : 5.5.2 Weitere Dokumente
  • : 6 Anhang B – Profilierung der Signatur- und Verschlüsselungsformate (normativ)
  • : : 6.1 Profilierung der Verschlüsselungsformate
  • : : 6.2 Profilierung der Signaturformate
  • : : 6.3 Profilierung VerificationReport
  • : : 6.4 Profilierung der Dokumentenformate und Nachrichten
  • : 7 Anhang F – Übersicht Events
  • : 8 Anhang H – Mapping von „Architektur der TI-Plattform“ auf Konnektorspezifikation
  • : 9 Anhang I – Umsetzungshinweise (informativ)
  • : : 9.1 Systemüberblick
  • : : : 9.1.1 – Hinweise zur Sicherheitsevaluierung nach Common Criteria
  • : : : : 9.1.1.1 Separationsmechanismen des Konnektors
  • : : : : 9.1.1.2 Granularität der TSF
  • : : 9.2 Übergreifende Festlegungen
  • : : : 9.2.1 Interne Mechanismen
  • : : : : 9.2.1.1 Zufallszahlen und Schlüssel
  • : : 9.3 Funktionsmerkmale
  • : : : 9.3.1 Anwendungskonnektor
  • : : : : 9.3.1.1 Administration des Informationsmodells
  • : : : : 9.3.1.2 Vorgehensvariante für das Handling von CardSessions
  • : : : : 9.3.1.3 Darstellung von Terminal-Anzeigen auf einem Kartenterminal
  • : 10 Anhang K – Szenarien im dezentralen Umfeld
  • : : 10.1 Szenario 1: Einfache Installation ohne spezielle Anforderungen und ohne bestehende Infrastruktur
  • : : : 10.1.1 Beschreibung des Szenarios
  • : : : 10.1.2 Voraussetzungen
  • : : : 10.1.3 Auswirkungen
  • : : 10.2 Szenario 2: Installation mit mehreren Behandlungsräumen
  • : : : 10.2.1 Beschreibung des Szenarios
  • : : : 10.2.2 Voraussetzungen
  • : : : 10.2.3 Auswirkungen
  • : : 10.3 Szenario 3: Integration in bestehende Infrastruktur ohne Netzsegmentierung
  • : : : 10.3.1 Beschreibung des Szenarios
  • : : : 10.3.2 Voraussetzungen
  • : : : 10.3.3 Auswirkungen
  • : : 10.4 Szenario 4: Integration in bestehende Infrastruktur mit Netzsegmentierung
  • : : : 10.4.1 Beschreibung des Szenarios
  • : : : 10.4.2 Voraussetzungen
  • : : : 10.4.3 Auswirkungen
  • : : 10.5 Szenario 5: Zentral gesteckter HBA
  • : : : 10.5.1 Beschreibung des Szenarios
  • : : : 10.5.2 Voraussetzungen
  • : : : 10.5.3 Auswirkung
  • : : 10.6 Szenario 6: Installation mit zentralem PS
  • : : : 10.6.1 Beschreibung des Szenarios
  • : : : 10.6.2 Voraussetzungen
  • : : : 10.6.3 Auswirkungen
  • : : 10.7 Szenario 7: Mehrere Mandanten
  • : : : 10.7.1 Beschreibung des Szenarios
  • : : : 10.7.2 Voraussetzungen
  • : : : 10.7.3 Auswirkungen
  • : : 10.8 Szenario 9: Standalone Konnektor - Physische Trennung
  • : : : 10.8.1 Beschreibung des Szenarios
  • : : : 10.8.2 Voraussetzungen
  • : : : 10.8.3 Auswirkung
  • : 11 Anhang L – Datentypen von Eingangs- und Ausgangsdaten
  • 1 Einordnung des Dokumentes

    1.1 Zielsetzung

    Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Konnektor.

    Dieses Dokument beschreibt die dezentrale Komponente zur sicheren Anbindung von Clientsystemen der Institutionen und Organisationen des Gesundheitswesens an die Telematikinfrastruktur – den Konnektor. Der Konnektor ist einerseits verantwortlich für den Zugriff auf die in der Einsatzumgebung befindlichen Kartenterminals sowie Karten und andererseits für die Kommunikation mit den zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten. Aus den Kommunikationsbeziehungen mit Clientsystem, Kartenterminals, Karten und zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten resultieren vom Konnektor anzubietende Schnittstellen, die gemeinsam in diesem Dokument sowie den fachanwendungsspezifischen Fachmodulspezifikationen normativ geregelt werden. Vom Konnektor genutzte Schnittstellen liegen zumeist in anderen Verantwortungsbereichen (zentrale TI-Plattform aber auch Schnittstellen der Kartenterminals und Karten). Diese werden in den übergreifenden Spezifikationen der TI sowie den Produkttypspezifikationen definiert.

    Dieses Dokument regelt somit nur einen Teil des Konnektors (wenngleich auch den Wesentlichen). Für die Implementierung eines Konnektors ist entsprechend die Kenntnis aller weiteren Spezifikationen erforderlich. Die Gesamtheit aller für den Konnektor relevanten Dokumente wird im Produkttypsteckbrief des Konnektors erhoben.

    1.2 Zielgruppe

    Das Dokument richtet sich an Konnektorhersteller sowie Hersteller und Anbieter von Produkttypen (dies beinhaltet auch die Anbieter zur G2-Ausschreibung), die hierzu eine Schnittstelle besitzen.

    1.3 Geltungsbereich

    Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des Deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

    Wichtiger Schutzrechts-/Patentrechtshinweis

    Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

    1.4 Abgrenzung des Dokuments

    Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.

    Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps Konnektor verzeichnet.

    1.5 Methodik

    1.5.1 Anforderungen

    Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

    Sie werden im Dokument wie folgt dargestellt:

    <AFO-ID> - <Titel der Afo>
    Text / Beschreibung
    [<=]
    Dabei umfasst die Anforderung sämtliche innerhalb der Afo-ID und der Textmarke angeführten Inhalte.

    <AFO-ID> - *

    Das Zeichen '*' steht hierbei für den Suffix der Anforderung. Es gilt der im Dokumentenpaket gültige Suffix.

    1.5.2 Offene Punkte

    Zum Zeitpunkt der Spezifikationserstellung konnten nicht alle Details abschließend geklärt werden, insbesondere, da Abstimmungsbedarf mit der umsetzenden Industrie besteht. Details, die keine produkttypübergreifenden Auswirkungen haben und die im Rahmen des Verhandlungsverfahrens mit der Industrie besprochen werden müssen, werden als „Offene Punkte“ ausgewiesen und wie folgt im Dokument kenntlich gemacht:

    Die XYZ müssen noch definiert werden.

    1.5.3 Erläuterungen zur Spezifikation des Außenverhaltens

    Der Konnektor stellt einen vergleichsweise komplexen Produkttyp dar, dessen Beschreibung eine Herausforderung darstellt und somit in vielen verschiedenen Varianten möglich wäre. An dieser Stelle folgen daher wesentliche Informationen, die das korrekte Verstehen der Spezifikation fördern:

    Die Spezifikation des Konnektors ist eine Black-Box-Spezifikation, das heißt alle Festlegungen dienen ausschließlich der Beschreibung des von der Komponente verlangten Verhaltens an der Außenschnittstelle.

    Normative Festlegungen, die eine Festlegung des inneren Verhalten vermuten lassen (beispielsweise die Definitionen der Technischen Use Cases - TUCs) sind nur in so weit normativ, wie ihre Festlegungen auf die Außenschnittstelle wirken. Sie legen explizit nicht die intern zu verwendende Implementierung fest. Die Notwendigkeit für diese Art der „scheinbaren internen Beschreibung“ ergibt sich aus der Komplexität der Gesamtkomponente, sowie dem Bedarf, wiederholt ähnlich Verhaltensweisen in Außenschnittstellen darstellen zu müssen. In diesem Fall werden die sich wiederholenden Verhaltensanteile in internen TUCs zur editoriellen Wiederverwendung gekapselt. Die konkrete konnektorinterne Modularisierung bleibt dem Hersteller freigestellt. Insbesondere bleibt es dem Hersteller freigestellt, intern bereits Mechanismen für kommende Releases zu realisieren, sofern diese an der Außenschnittstelle keine Auswirkung zeigen.

    Die einzige Abweichung von dieser Vorgehensweise ergibt sich für Sicherheitsaspekte. Hier können interne Vorgänge normativ gefordert sein, die sich an der Außenschnittstelle nicht manifestieren (Beispiel „Verpflichtung auf sicheres Löschen eines temporären Schlüssels nach Gebrauch“). In diesem Fall erfolgt die Überprüfung der Einhaltung dieser Anforderungen im Rahmen der CC-Evaluierung.

    1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“

    1.5.4.1 Modulare Spezifikation über Funktionsmerkmale

    Die Beschreibung des Konnektors erfolgt soweit wie möglich modular, d. h. alle Aspekte, die für einen logischen Bereich relevant sind, werden in einem Kapitel beschrieben. Diese logischen Bereiche werden als Funktionsmerkmal bezeichnet.

    Funktionsmerkmale kennzeichnet ein eigener Verantwortungsbereich. In diesen Verantwortungsbereich greifen keine anderen Funktionsmerkmale ein. So kann ein logischer Bereich vollständig durchdrungen werden, ohne dass in anderen Kapiteln Anforderungen zu erwarten wären, die das Verhalten des Funktionsmerkmals beeinflussen. Da zwischen Funktionsmerkmalen Wechselwirkungen bestehen (Die Erkennung einer gesteckten Karte im Kartenterminaldienst löst eine Reaktion im Kartendienst aus), wurden zur „dokumententechnischen Interaktion“ zwischen Funktionsmerkmalen ein interner Event-Mechanismus sowie Konfigurationsparameter und Zustandswerte eingeführt (siehe Folgekapitel).

    Funktionsmerkmale bestehen (bis auf wenige Ausnahmen) immer aus folgenden Unterkapiteln:

    1. Funktionsmerkmalweite Aspekte
    2. Durch Ereignisse ausgelöste Reaktionen
    3. Interne TUCs, nicht durch Fachmodule nutzbar
    4. Interne TUCs, auch durch Fachmodule nutzbar
    5. Operationen an der Außenschnittstelle
    6. Betriebsaspekte

    Die Unterkapitel 1-5 dienen der funktionalen Beschreibung des Funktionsmerkmals.

    Punkte, die zum Funktionieren des Funktionsmerkmals relevant sind: Initialisierungsaspekte, durch den Administrator festzulegenden Konfigurationsparameter etc., werden im Unterkapitel Betriebsaspekte erfasst.

    In jedem Funktionsmerkmal sind immer alle Unterkapitel enthalten, auch wenn es im konkreten Einzelfall dort keine Inhalte gibt. Diese feste Struktur innerhalb der Funktionsmerkmale erleichtert die Orientierung und erhöht somit die Lesbarkeit.

    1.5.4.2 Technische Use Cases - TUCs

    Innerhalb der Funktionsmerkmale in Kapitel 4 erfolgt eine Unterscheidung der TUCs in solche, die nur durch die Basisdienste des Konnektors aufgerufen werden dürfen (rein interne TUCs) und solche die neben den Basisdiensten auch durch Fachmodule genutzt werden dürfen. Diese Unterteilung ergibt sich ausschließlich aus dem Bedarf der editoriellen Steuerung der verschiedenen Spezifikationen (Konnektor- und Fachmodulspezifikationen). Es besteht im Rahmen der Implementierung des Konnektors keine Anforderung diese Trennung intern durchzusetzen.

    Die Beschreibung der TUCs erfolgt nach folgendem Muster:

    Dabei wird innerhalb der TUC-Tabelle in der Zeile „Standardablauf“ ausschließlich der Gut-Durchlauf beschrieben. Fehler, die innerhalb dieses Ablaufs auftreten können, werden in der Zeile „Fehlerfälle“ erhoben. Dabei wird auf die jeweilige Schrittnummer innerhalb des Ablaufs referenziert. In dieser Tabellenzeile werden nur Fehlercodes erhoben, die im jeweiligen Fehlerfall geworfen werden müssen. Die genauen Festlegungen zu den Fehlern, neben Fehlercode auch: ErrorType, Severity und Fehlertext, werden in der Fehlercodetabelle festgelegt.    

    Die Spezifikation, in der ein TUC definiert wird, ist an den mittleren drei Buchstaben der TUC-Referenz zu erkennen:

    Festlegungen zur Schreibweise von Eingangs- und Ausgangsdaten von TUCs

    a) Eingangs- und Ausgangsparameter werden in TUC-Tabellen wie folgt beschrieben:

    Name des Eingangs- bzw. Ausgangsparameters

    gefolgt von (falls definiert):[Datentyp]

    gefolgt von (falls zutreffend):

    - optional; default: <Defaultwert> bzw.

    - optional;/<erklärender Text>  

    Hierbei bedeuten:

    - optional; kennzeichnet optionale Ein- und Ausgangsparameter

    default: <Defaultwert> definiert den Defaultwert für den Fall, dass der Eingangsparameter leer ist bzw. nicht übergeben wurde

    / <erklärender Text> beschreibt Bedingungen, unter denen der Eingangsparameter optional ist

         gefolgt von (falls vorhanden):(<erklärender Text>)

    b) Namen mit kleinem Anfangsbuchstaben bezeichnen Ein- und Ausgangsparameter; Namen mit großem Anfangsbuchstaben bezeichnen Datentypen.

    Beispiel:

    Eingangsdaten
    • mandantId
    • allWorkplaces [Boolean] – optional; default: false
      (Dieser Schalter gibt an, ob eine mandantenweite Zugriffsberechtigung zum Tragen kommt…)
    • userId - optional/verpflichtend, wenn cardType = HBAx
    Ausgangsdaten
    • pinStatus [PinStatus]
    • leftTries – optional/verpflichtend, wenn pinStatus = VERIFYABLE
      (Anzahl der verbleibenden Versuche für die Verifikation der PIN)


    Die im Dokument verwendeten Datentypen sind definiert in [Anhang L – Datentypen von Eingangs- und Ausgangsdaten].

    Festlegungen zur Schreibweise des Aufrufs von TUCs

    Ein TUC-Aufruf erfolgt nach folgendem Muster:

    <TUC-Bezeichner> {

       <TUC-Eingangsparameter Name> = <TUC Eingangsparameter Wert>;

       … }

    Beispiel:

    TUC_KON_256 {
        topic = „CT/DISCONNECTED“;
        eventType = Op;
        severity = Info;
        parameters = („CtID=$CT.CTID, Hostname=$CT.HOSTNAME“) }

    Vereinfachung:

    Ist <TUC-Eingangsparameter Name> des aufzurufenden TUCs gleich der Variablen, die als < TUC Eingangsparameter Wert> gesetzt wird, so kann dieser Bezeichner ohne Zuweisung geschrieben werden.

    Beispiel: (cardSession und pinRef sind Eingangsdaten des aufrufenden TUCs):

    TUC_KON_022 „Liefere PIN-Status“ {cardSession=cardSession; pinRef=pinRef}

    vereinfachte Schreibweise:

    TUC_KON_022 „Liefere PIN-Status“ {cardSession; pinRef}

    1.5.4.3 Event-Mechanismus

    Der in Kapitel 4.1.6 spezifizierte Event-Mechanismus zur Unterrichtung von Clientsystemen wird innerhalb dieser Spezifikation auch zur internen Verzahnung der einzelnen Funktionsmerkmale eingesetzt. So wird ein Ereignis, das in der Managementschnittstelle durch Änderung eines Konfigurationsparameters ausgelöst wird, innerhalb des DHCP-Kapitels als Trigger für eine Lease-Erneuerung verwendet. Dies bedeutet nicht, dass im Rahmen der Implementierung intern ein Event-Mechanismus zwischen den Modulen verwendet werden muss. Auch hier dient die Form der Darstellung (Events) lediglich der editoriellen Kopplung verschiedener Verhaltensbeschreibungen.

    Um den Ursprung eines Events erkennen zu können, verwenden alle Events ein Haupt-Topic passend zum Funktionsmerkmal: „DHCP/LAN_CLIENT/RENEW” wird im Funktionsmerkmal DHCP ausgelöst, „CARD/INSERTED” wird im Funktionsmerkmal Kartendienst ausgelöst usw.     

    1.5.4.4 Konfigurationsparameter und Zustandswerte

    Werte die der Administrator des Konnektors einsehen oder verändern können muss, werden zusätzlich zu den Festlegungen in Kapitel 4.3 Konnektormanagement auch pro Funktionsmerkmal in den jeweiligen Unterkapiteln „Betriebsaspekte“ erhoben. Diese Konfigurationsparameter werden über eine ReferenzID definiert. Definierte Konfigurationsparameter können in allen Kapiteln der Spezifikation referenziert werden. Den Ort, an welchem ein solcher Konfigurationsparameter definiert/erhoben und somit dessen Bedeutung beschrieben wird, lässt sich über den Präfix der ReferenzID erkennen: CERT_CRL_DOWNLOAD_ADDRESS (also „Cert“) wird im Zertifikatsdienst definiert, MGM_LU_ONLINE (also „MGM“) wird im Konnektormanagement definiert usw.

    Die ReferenzIDs der Konfigurationsparameter besitzen in ihrer Schreibweise nur innerhalb des Dokuments Gültigkeit. In der Umsetzung können für die Konfigurationswerte herstellerspezifische Beschreibungen und Labels verwendet werden.

    Vergleichbar zu diesen Konfigurationsparametern, sind Zustandswerte. Auch diese werden über ReferenzIDs definiert, nur können sie nicht durch den Administrator verändert oder eingesehen werden. Sie finden nur konnektorintern Verwendung und sind für die Beschreibung der Verhaltensweise notwendig, Beispiele sind CTM_CT_LIST für die Liste der durch den Konnektor verwalteten Kartenterminals oder CM_CARD_LIST für die Liste der aktuell erreichbaren Karten. Zustandswerte verwenden die gleichen Präfixe wie Konfigurationsparameter.

    2 Systemüberblick

    Der Konnektor ist ein Produkttyp der TI gemäß [gemKPT_Arch_TIP#5.3.9].

    Er bietet seine Basisdienste sowohl intern den in ihm laufenden Fachmodulen an, als auch externen Clientsystemen über die Konnektoraußenschnittstellen.

    Im lokalen Netz der Einsatzumgebung kommuniziert das Clientsystem mit dem Konnektor über dessen LAN-seitiges Ethernet-Interface. Alleinig der Konnektor kommuniziert mit den in lokalen Netzen angeschlossenen Kartenterminals und Karten. Auch die Kommunikation mit den zentralen Diensten der TI-Plattform und fachanwendungsspezifischen Diensten erfolgt ausschließlich über den Konnektor über dessen WAN-seitiges Ethernet-Interface.

    Abbildung PIC_KON_116 stellt die Schnittstellen im Umfeld des Konnektors dar.


    Abbildung 1: PIC_KON_116 Schnittstellen des Konnektors von und zu anderen Produkttypen

    Die logischen Außenschnittstellen aus [gemKPT_Arch_TIP] werden im Konnektor technisch vorrangig als SOAP-Schnittstellen ausgeprägt. Von dieser Regel wird insbesondere bei Netzwerkschnittstellen abgewichen, wenn bereits etablierte Schnittstellenstandards für Basisdienste existieren (IPsec, TLS, NTP, DNS etc.). Eine Übersicht der Zuordnung „logische Schnittstellen technische Schnittstellen“ findet sich in Anhang H.

    Zum Nachweis der Sicherheit müssen Konnektoren im Rahmen der Zulassung nach Common Criteria gegen die Schutzprofile [PP_NK] und [PP_KON] evaluiert und zertifiziert werden.

    Die zu verwendenden kryptographischen Verfahren und zugehörige Parameter (z. B. Schlüssellängen) für alle kryptographischen Operationen innerhalb der Telematikinfrastruktur, werden durch das Dokument „Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur“ [gemSpec_Krypt] normativ geregelt.

    2.1 Logische Struktur

    Der Produkttyp Konnektor besitzt eine Vielzahl verschiedenster Operationen und Verhaltensweisen an seiner Außenschnittstelle. Um sein komplexes Gesamtverhalten sinnvoll beschreiben zu können, wird der Konnektor innerhalb dieser Spezifikation logisch unterteilt und strukturiert. Es wird primär zwischen Anwendungs- und Netzkonnektor unterschieden, begleitet von Mechanismen, die blockübergreifend beschrieben werden.

    Der logische Aufbau des Konnektors ist in Abbildung PIC_KON_117 dargestellt.

    Abbildung 2: PIC_KON_117 Logische Zerlegung des Konnektors in Anwendungs- und Netzkonnektor

    Diese logische Unterteilung schreibt in keiner Art und Weise die spätere Implementierung durch den Hersteller vor. Der Hersteller kann seine interne Modularisierung des Konnektors frei wählen. Normativ wirksam ist ausschließlich das durch die Detailfestlegungen in Summe beschriebene Verhalten an den Außenschnittstellen des Konnektors als Ganzes.

    2.2 Sicherer Datenspeicher

    Wie im vorherigen Kapitel dargestellt, wird für den Konnektor ein Datenspeicher angenommen, in welchem der Konnektor alle sicherheitskritischen, veränderlichen Daten dauerhaft speichert, die für seinen Betrieb relevant sind. Dieser Datenspeicher sichert die Integrität, Authentizität und Vertraulichkeit der in ihm hinterlegten Daten bzw. der aus ihm entnommenen Daten. Alleinig der Konnektor hat auf diesen Datenspeicher Zugriff. Für folgende, im weiteren Verlauf der Spezifikation anfallende Daten wird angenommen, dass diese im Sicheren Datenspeicher persistiert werden:

    Ferner stellt der Konnektor den in ihm laufenden Fachmodulen ebenfalls eine Nutzung dieses Datenspeichers für ihre sensiblen Daten zur Verfügung.

    Da es sich bei dem Sicheren Datenspeicher um ein internes Modul handelt, welches an der Außenschnittstelle nicht testbar ist, werden an dieses Modul im Rahmen dieser Spezifikation keine Anforderungen erhoben. Da dieses logische Modul aber essenzielle Sicherheitsfunktionen bietet, ohne die ein Konnektor nicht sicher betrieben werden kann, werden die Funktionen, die ein Hersteller für sein Konnektormodell real umsetzt, um die notwendigen sicheren Speicherfunktionen zu realisieren, im Rahmen der CC-Evaluierung geprüft werden. Näheres hierzu regeln die Schutzprofile des Konnektors.

    2.3 Überblick Konnektoridentität

    Die Geräteidentität des Konnektors (Konnektoridentität) teilt sich in drei Identitäten auf:

    In der Regel ergibt sich aus dem Kontext, welche Identität gemeint ist, sodass in diesen Fällen nur kurz von der Konnektoridentität geschrieben wird.

    Die Geräteidentitäten werden durch asymmetrische Schlüssel und X.509-Zertifikate umgesetzt. In Abhängigkeit vom gewählten kryptographischen Verfahren werden RSA-Schlüssel bzw. ECC-Schlüssel verwendet.

    2.4 Mandantenfähigkeit

    Den Anforderungen aus [gemKPT_Arch_TIP#TIP1-A_2200] folgend, wird die Mandantenfähigkeit innerhalb des Konnektors nicht durch eine einzelne Funktion, sondern durch Berücksichtigung in einer Reihe von Funktionsmerkmalen umgesetzt.

    Die Mandantenfähigkeit wirkt dabei auf:

    2.5 Versionierung

    Gemäß [gemSpec_OM] müssen Konnektor und Kartenterminals über eine Versionierung verfügen. Die relevanten Versionsinformationen sind durch das O&M-Schema ProductInformation.xsd definiert. Ferner definiert [gemSpec_OM], dass Konnektor und Kartenterminal das Konzept der Firmware-Gruppe verwenden müssen. Daher verfügen die beiden Produkttypen auch über eine aktuelle Firmware-Gruppenversion.

    Versionsinformationen werden innerhalb des Konnektor an folgenden Stellen ver- und bearbeitet:

    2.6 Fachanwendungen

    Der Konnektor ist als Plattformkomponente der TI für die Erbringung von Basisdiensten verantwortlich. Fachliche Funktionalitäten werden über die Fachmodule bereitgestellt.

    Das Fachmodul wird dabei als integraler Bestandteil des Konnektors verstanden (Konnektor als Monolith), d. h., die Spezifikationen zu Konnektor (als Plattformkomponente) und dem Fachmodul sind zwar getrennt, werden aber von einem Hersteller in einer Gesamtkomponente umgesetzt. Die inneren Schnittstellen zwischen Fachmodul und Konnektor sind von außen nicht erkennbar.

    In dieser Ausbaustufe unterstützt der Konnektor die Fachanwendungen VSDM, AMTS, NFDM und ePA über jeweils ein Fachmodul.

    Neben Fachanwendungen, die über ihr Fachmodul mit einem gesicherten Fachdienst kommunizieren, unterstützt der Konnektor einen Zugriff von Clientsystemen auf offene Fachdienste.

    2.7 Netzseitige Einsatzszenarien

    Der Konnektor unterstützt unterschiedliche netzseitige Einsatzszenarien, die in Anhang K beispielhaft dargestellt sind.

    Der Konnektor bietet hierzu Konfigurations-Parameter, die je nach netzseitigem Einsatzszenario konfiguriert werden müssen.

    2.7.1 Parameter ANLW_ANBINDUNGS_MODUS

    Konfiguration 1: Konnektor als Gateway (ANLW_ANBINDUNGS_MODUS = InReihe):
    Diese Konfiguration ist geeignet für Szenarien, in denen der Konnektor zwischen das lokale Netz und das Internet Access Gateway (IAG) (z. B. Router mit DSL-/Kabelmodem) geschaltet wird. (vgl. Anhang K, Szenario 1)

    Konfiguration 2: Konnektor eingebettet in existierende Infrastruktur (ANLW_ANBINDUNGS_MODUS = Parallel): Diese Konfiguration ist geeignet für Szenarien, in denen der Konnektor als weiteres Gerät in die bestehende Netzwerkinfrastruktur integriert wird. (vgl. Anhang K, Szenario 3)

    Aus Sicherheitsgründen soll die Kommunikation der Clientsysteme mit dem Konnektor hierbei verschlüsselt erfolgen (ANCL_TLS_MANDATORY=Enabled). Falls diese Kommunikation unverschlüsselt erfolgt (ANCL_TLS_MANDATORY=Disabled), übernimmt der Nutzer die Verantwortung für die Sicherstellung der vertraulichen Übertragung.

    Für den Einsatz und die Nutzung von DHCP gibt es im Zusammenhang mit diesem Konfigurationsparameter folgende Möglichkeiten:

    Die DHCP-Konfiguration ist in Konfiguration 1 in aller Regel die folgende: Die WAN-Seite des Konnektors verwendet den DHCP-Server des bestehenden IAG. An der LAN-Seite stellt der Konnektor einen DHCP-Server für alle Clients zur Verfügung.

    2.7.2 Parameter ANLW_INTERNET_MODUS

    Grundsätzlich routet der Konnektor im Modus ANLW_INTERNET_MODUS=SIS alle für das Internet bestimmten Pakete von Clients, die ihn als Default Gateway verwenden, in den VPN-Tunnel zum SIS, während er im Modus ANLW_INTERNET_MODUS=Keiner diese Pakete verwirft.

    Im Unterschied zu (ANLW_ANBINDUNGS_MODUS = InReihe) ist die Nutzung des SIS bei (ANLW_ANBINDUNGS_MODUS = Parallel) optional. Alternativ können auch die Clients, die den Konnektor als Default Gateway verwenden, per Redirect direkt ins Internet verwiesen werden (ANLW_INTERNET_MODUS=IAG).

    2.8 Lokale und entfernte Kartenterminals

    Gemäß [gemKPT_Arch_TIP] ermöglicht die Telematikinfrastruktur dem Anwender die PIN-Eingabe zur Freischaltung eines HBAs oder einer SMC-B wahlweise lokal oder über das Remote-PIN-Eingabeverfahren durchzuführen. Deshalb unterscheidet auch der Konnektor zwischen einem lokalen Kartenterminal – räumlich („in Sichtweite“) dem Arbeitsplatz zugeordnet – und einem entfernten Kartenterminal.

    Ein lokales Kartenterminal befindet sich lokal an einem Arbeitsplatz und kann von diesem aus genutzt werden. Hingegen ist das entfernte Kartenterminal einem entfernten oder auch – für zentral steckende Karten – keinem Arbeitsplatz fest zugewiesen. Ein lokales Kartenterminal kann als sogenanntes Remote-PIN-KT verwendet werden, um die PIN für eine in einem entfernten Kartenterminal steckende Karte einzugeben.

    2.9 Standalone-Szenario

    Gemäß § 291 Absatz 2b SGB V müssen „Diese Dienste [zur Online-Aktualisierung der Versichertendaten auf der eGK] […] auch ohne Netzanbindung an die Praxisverwaltungssysteme der Leistungserbringer online genutzt werden können.“

    Dies bedeutet, dass der Konnektor ohne ein steuerndes Clientsystem ereignisgetrieben Fachanwendungen ausführen können muss. Aus Fachsicht „steht der Konnektor alleine“, ohne Clientsysteme. Die konkreten Aktionen, die Fachanwendungen in diesen Fällen ausführen, sowie deren Auslöser werden in den jeweiligen Fachmodulspezifikationen beschrieben.

    Ein solcher alleinstehender Konnektor mit Zugang zur TI muss zur Durchführung der Fachanwendungen durch einen weiteren Konnektor unterstützt werden, der in direkter Verbindung zum Clientsystem steht, selbst aber keine Online-Anbindung besitzt.

    3 Übergreifende Festlegungen

    Für die folgenden Inhalte bitte die Hinweise in Kapitel 1.5.3 „Erläuterungen zur Spezifikation des Außenverhaltens" sowie Kapitel 1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“ beachten.

    In diesem Kapitel werden die Aspekte des Konnektors behandelt, die Funktionsmerkmalübergreifend geregelt werden müssen.

    Die Managementschnittelle/Administrationsoberfläche des Konnektors wird dabei nicht als übergreifender Aspekt, sondern als eigenes Funktionsmerkmal gewertet. Die Festlegungen hierzu finden sich entsprechend in Kapitel 4.3.

    3.1 Allgemeine übergreifende Festlegungen

    3.1.1 Dokumentformate

    Mit dem Aufruf einer Operation, die Dokumente verarbeitet, muss durch den Aufrufer festgelegt werden können, um welches Dokumentenformat es sich handelt, damit die unterschiedlichen Formate zur Verarbeitung und etwaigen Anzeige unterschieden werden können. Die nicht-XML-Formate werden dabei nach MIME-Typ-Klassen unterschieden:

    Folgende Bezeichner werden verwendet:

    Alle_DocFormate:      XML, PDF/A, Text, TIFF, Binär

    nonQES_DocFormate:    XML, PDF/A, Text, TIFF, Binär

    QES_DocFormate       XML, PDF/A, Text, TIFF

    Für nonQES_DocFormate wird, trotz Gleichheit zu Alle_DocFormate, ein eigener Referenzbezeichner verwendet, da sich diese Liste noch ändern könnte. TIFF wird durch [gemKPT_Arch_TIP] nicht für die nonQES verlangt. Die Unterstützung dieses Formats für nonQES bedeutet jedoch keinen Mehraufwand, da die Routinen durch QES bereits implementiert sind und nachgenutzt werden können.

    TIP1-A_4500-02

    Der Konnektor MUSS für alle Außenschnittstellen, in denen ein Dokument verarbeitet wird, Dokumente mit einer Größe <= 25 MB (26.214.400 Byte) unterstützen. Der Konnektor DARF NICHT Dokumente mit einer Größe > 25 MB (26.214.400 Byte) unterstützen. <=

    A_19052-01

    Der Konnektor MUSS bei der Verarbeitung von Dokumenten und Nachrichten die Mindestanforderungen aus TAB_KON_775 erfüllen. Wenn vom Aufrufer übergebene Dokumente oder Nachrichten die vom Konnektor unterstützte Dimensionierung überschreiten, MUSS der Konnektor die Verarbeitung mit Fehler 4280 abweisen.

    Tabelle 1 Fehlercodes TAB_KON_890 Mindestanforderungen an Dokumente und Nachrichten

    Fehlercode ErrorType Severity Fehlertext
    4280 Security Error Dimensionierung des Dokuments nicht unterstützt
    <=

    A_22673

    Der Konnektor MUSS bei der Verarbeitung von Dokumenten und Nachrichten die Einhaltung der Vorgaben aus TAB_KON_889 sicherstellen. Wenn vom Aufrufer an den Konnektor übergebene Dokumente oder Nachrichten gegen Vorgaben aus TAB_KON_778 verstoßen, MUSS der Konnektor die Verarbeitung mit Fehler 4281 abbrechen.

    Tabelle 2 Fehlercodes TAB_KON_891 Unerlaubte Inhalte in Dokumenten und Nachrichten

    Fehlercode ErrorType Severity Fehlertext
    4281 Security Error Dokument enthält unzulässige Inhalte
    <=

    A_22923

    Der Konnektor DARF in XML-Dokumenten- und Nachrichten enthaltene Attribute schemaLocation und noNamespaceSchemaLocation NICHT auswerten. <=

    TIP1-A_4502

    Der Konnektor MUSS bei der Verarbeitung von Dokumenten der Formate XML und Text die Zeichensatzkodierungen UTF-8 und ISO-8859-15 unterstützen. Das verarbeitete Dokument MUSS der Konnektor mit demselben Zeichensatz kodieren, in dem das Eingangsdokument kodiert war. <=

    TIP1-A_5541-01

    Der Konnektor DARF in Dokumenten eventuell vorhandene Referenzen auf externe Ressourcen NICHT auflösen, es sei denn es sind Verweise auf im Konnektor sicher eingebrachte vorliegende Schemata oder dies wird im Einzelfall normativ gefordert. <=

    3.1.2 Kartentypen

    Der Konnektor unterstützt eine Reihe von Kartentypen. Die folgende Tabelle enthält die Liste der Referenzbezeichner für die verschiedenen Kartentypen, wie sie im weiteren Verlauf verwendet werden. Die Unterstützung von Karten der Generation 2 (G2.x: G2.0, G2.1 und höher) beschränkt sich bei diesen auf die Datenstrukturen und Schlüssel, die aus Gründen der Abwärtskompatibilität zu den Karten der Generation 1+ vorhanden sind. Eine Ausnahme hiervon bilden die Geräte-CVCs, die bereits für dieses Release basierend auf ECC verwendet werden.

    Tabelle 3: TAB_KON_500 Wertetabelle Kartentypen

    ReferenzID Kartentyp
    Karten-
    generation
    Beschreibung
    EGK
    G1+
    Die elektronische Gesundheitskarte gemäß [gemSpec_eGK_P1] und [gemSpec_eGK_P2]
    EGK
    G2
    Die elektronische Gesundheitskarte gemäß [gemSpec_COS] und [gemSpec_eGK_ObjSys] bzw. [gemSpec_eGK_ObjSys_G2.1]
    HBA-qSig
    -
    HBA-Vorläuferkarte gemäß [HPC-P1] und [HPC-P2]
    HBA
    G2
    Der elektronische Heilberufsausweis (HBA) gemäß [gemSpec_COS] und [gemSpec_HBA_ObjSys]
    SMC-B
    G2
    Die Institutionskarte Typ B (Secure Module Card) gemäß [gemSpec_COS] und [gemSpec_SMC-B_ObjSys]
    HSM-B

    HSM-Variante einer SM-B.
    Das HSM-B wird in dieser Fassung als ein oder mehrere virtuelle Kartenterminals verstanden, in denen virtuelle Karten stecken.
    SMC-KT
    G2
    Die Karte Typ KT (Secure Module Card) gemäß [gemSpec_COS] und [gemSpec_gSMC-KT_ObjSys]
    KVK
    -
    Die Krankenversichertenkarte gemäß der Spezifikation [KVK]
    ZOD_2.0
    -
    HBA-Vorläuferkarte gemäß [HPC-P1] und [HPC-P2]
    UNKNOWN

    Eine nicht erkannte Karte oder nicht lesbare Karte


    Zusammenfassende ReferenzIDs
    HBA-VK

    Adressiert die HBA-Vorläuferkarten HBA-qSig und ZOD_2.0.
    Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für beide Kartentypen.
    HBAx

    Adressiert sowohl den HBA, als auch die HBA-Vorläuferkarten (HBA-VK)
    Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für alle drei Kartentypen.
    SM-B

    Adressiert sowohl eine echte SMC-B als auch eine in einem HSM-B enthaltene virtuelle SMC-B.
    Wird dieser Referenzbezeichner verwendet, gelten die zugehörigen Aussagen und Festlegungen für beide Typen.

    3.1.3 Übergreifende Festlegungen zum Aufbau von sicheren Verbindungen

    TIP1-A_7254

    Der Konnektor MUSS beim Aufbau von TLS-gesicherten Verbindungen zu einem zentralen Dienst der TI-Plattform oder zu einem fachanwendungsspezifischen Dienst, bei denen eine OCSP-Abfrage des Serverzertifikats nach TUC_PKI_006 erfolgt, neben Fehlerfällen bei folgenden Warnungen gemäß [gemSpec_PKI#Tab_PKI_274]

    mit Abbruch des Verbindungsaufbaus reagieren. <=

    In [gemSpec_Krypt#6] wird das Kommunikationsprotokoll zwischen einem Client und einer Vertrauenswürdigen Ausführungsumgebung (VAU) spezifiziert. Dabei wird ein sicherer Kanal auf HTTP-Anwendungsschicht zwischen dem Client und der VAU (Server) aufgebaut. Der Client ist hier ein Fachmodul des Konnektors; der Server ist ein Fachdienst.

    A_17225-01

    Der Konnektor MUSS für Fachmodule den Aufbau einer sicheren Verbindung zur Vertrauenswürdigen Ausführungsumgebung (VAU) gemäß Kommunikationsprotokoll [gemSpec_Krypt#6] unterstützen und das vom Server übergebene Zertifikat wie folgt prüfen:
    TUC_KON_037 „Zertifikat prüfen“  {
           certificate = C.FD.AUT;
           qualifiedCheck = not_required;
           offlineAllowNoCheck = false;
           policyList  = oid_fd_aut;
           intendedKeyUsage= intendedKeyUsage(C.FD.AUT);
           validationMode  = OCSP}
    Der Konnektor MUSS die vom Fachmodul übergebene Rolle gegen die aus dem Zertifikat ermittelte Rolle prüfen.   <=

    A_17777

    Der Konnektor MUSS für Fachmodule für die Nutzung der Schlüsselableitungsfunktionalität die sicherheitstechnischen Festlegungen gemäß [gemSpec_Krypt#3.15.5 Schlüsselableitungsfunktionalität ePA] und [gemSpec_SGD] bereitstellen. <=

    Der Gesamtablauf der Schlüsselableitungsfunktionalität gemäß [gemSpec_SGD#2.3] für den Konnektor als Client ist aufgeteilt zwischen Basiskonnektor und Fachmodul. Die kryptographischen Vorgaben (u.a. Durchführung des ECDH, Schlüsselerzeugung, Ver- und Entschlüsselung, Signaturerzeugung und -prüfung) werden dabei durch den Basiskonnektor realisiert.

    3.2 Konnektoridentität und gSMC-K

    TIP1-A_4503

    Der Konnektor MUSS das geheime Schlüsselmaterial zur Geräteidentität (ID.NK.VPN, ID.AK.AUT, ID.SAK.AUT) und der Rolle SAK (C.SAK.AUTD_CVC) über Smartcards des Typs gSMC-K gemäß [gemSpec_gSMC-K_ObjSys] nutzen. Der Konnektor MUSS mit einer gSMC-K bestückt sein. Er KANN mit mehr als einer gSMC-K bestückt sein.

    <=

    Die Notwendigkeit, den Konnektor mit mehr als einer gSMC-K zu bestücken, kann sich aus den Lastanforderungen aus [gemSpec_Perf#4.1.2] ergeben.

    TIP1-A_4504

    Verwendet der Konnektor mehrere gSMC-Ks, DARF eine Administratorinteraktion für diese Belange NICHT erforderlich sein.

    <=

    TIP1-A_5543

    Der Konnektor DARF Anwender und Administratoren außer bei der Inbetriebnahme (erstmalig oder nach Werksreset) NICHT auffordern, eine PIN für eine gSMC-K einzugeben.

    <=

    TIP1-A_4505

    Die gSMC-K des Konnektors MÜSSEN durch den Einsatz physikalischer Sperren oder manipulationssicherer Siegel so mit dem Konnektor verbunden sein, dass physischer Missbrauch oder physische Manipulation erkennbar ist.

    <=

    gSMC-Ks gemäß [gemSpec_gSMC-K_ObjSys] verfügen über die Möglichkeit zur nachträglichen Generierung von Schlüsselpaaren und dem Nachladen der zugehörigen Zertifikate. Dieser Mechanismus wird erst in kommenden Releases durch den Konnektor unterstützt. Initial sind alle Identitäten bereits einmal auf der gSMC-K vorhanden.

    TIP1-A_4506

    In Abhängigkeit vom kryptographischen Verfahren MUSS der Konnektor folgende Objekte der gSMC-K als Quelle seiner Identitäten verwenden:

    Tabelle 4: TAB_KON_856: Identitäten des Konnektors auf der gSMC-K


    Identifier

    Verzeichnis
    Objekt der gSMC-K in Abhängikeit vom kryptographischen Verfahren
    RSA ECC
    ID.NK.VPN MF/DF.NK EF.C.NK.VPN.R2048  EF.C.NK.VPN2.XXXX
    ID.AK.AUT MF/DF.AK EF.C.AK.AUT.R2048 EF.C.AK.AUT2.XXXX
    ID.SAK.AUT MF/DF.SAK EF.C.SAK.AUT.R2048 EF.C.SAK.AUT2.XXXX
    C.SAK.AUTD_CVC MF/DF.SAK - EF.C.SAK.AUTD_CVC.E256

    <=

    A_21849

    Der Konnektor MUSS dem Administrator anzeigen, welche Zertifikate aktuell verwendet werden. Dies gilt für diese Strecken bzw. Anwendungsfälle: VPN-Tunnel (C.NK.VPN), TLS zum PS (C.AK.AUT oder lokales Zertifikat), TLS zum KT (C.SAK.AUT) und C2C für SUK (C.SAK.AUTD_CVC und C.CA_SAK.CS). <=

    3.2.1 Organisatorische Anforderungen und Sperrprozesse

    TIP1-A_5392

    Der Hersteller des Konnektors MUSS die Rolle des Kartenherausgebers für in seinen Konnektoren verbauten gSMC-Ks einnehmen.

    Der Hersteller des Konnektors KANN die von ihm verantwortete Personalisierung der gSMC-K durch einen von ihm zu beauftragenden Dienstleister in seinem Namen vornehmen lassen.

    <=

    TIP1-A_5696

    Der Hersteller des Konnektors MUSS sich von der korrekten Personalisierung der herausgegebenen gSMC-K überzeugen.

    <=

    A_18928

    Der Hersteller des Konnektors MUSS die Konnektoren mit einer gSMC-K mit personalisierten RSA- und ECC-Zertifikaten gemäß TAB_KON_856 ausstatten. <=

    A_18930

    Der Konnektor MUSS unterschiedliche gSMC-K-Personalisierungsvarianten sowohl mit als auch ohne ECC-Zertifikate für ID.NK.VPN, ID.AK.AUT und ID.SAK.AUT unterstützen. <=

    Die Anforderung ist für die Anwendungsfälle Registrierung, IPsec-Authentisierung und Autorisierung beim VPN-Zugangsdienst, TLS-Authentisierung zum eHealth-Kartenterminal, TLS-Authentisierung zum Primärsystem nachzuweisen. Wenn RSA-2048 in der TI abgekündigt wird, entfällt dadurch die Anforderung.

    TIP1-A_5393

    Der Hersteller des Konnektors MUSS die Zuordnung von Konnektor und jeweils eingebrachtem C.NK.VPN-Zertifikat mit dem Ziel dokumentieren, anhand eines Sperrauftrages für einen Konnektor, das zu sperrende C.NK.VPN-Zertifikat identifizieren zu können.

    <=

    Das bedeutet, dass der Konnektorhersteller je Konnektor die für die Identifikation des C.NK.VPN-Zertifikates relevanten Daten wie z. B. Seriennummer des Konnektors und Art der verbauten Komponenten, Seriennummer der gSMC-K, etc. für seinen Sperrprozesse dokumentieren muss.

    TIP1-A_5394

    Der Hersteller des Konnektors MUSS für die von ihm verantworteten Konnektoren einen Sperrprozess etablieren, unterhalten und der gematik zugänglich machen.

    Der Hersteller des Konnektors KANN die operative Durchführung des Sperrprozesses an Dritte delegieren.

    <=

    Sperrberechtigt ist die gematik im Rahmen des Change-Verfahrens (siehe [gemRL_Betr_TI#5.4).

    TIP1-A_5395

    Der Hersteller des Konnektors MUSS im Rahmen der Change-Durchführung erteilte Sperraufträge der gematik fristgemäß (gemäß Change-Auftrag) bei dem TSP X.509 nonQES (Zertifikatsaussteller) umsetzen.

    <=

    Dazu bedient er die standardmäßige Schnittstelle zum TSP (siehe [gemSpec_X.509_TSP#TIP1-A_3643]).

    TIP1-A_5396

    Der Hersteller des Konnektors MUSS vor der Umsetzung des Sperrauftrages für einen Konnektor die Sperrberechtigung des Beauftragenden prüfen und verhindern, dass Konnektoren missbräuchlich gesperrt werden.

    <=

    TIP1-A_5397

    Der Hersteller des Konnektors MUSS nach erfolgreicher Prüfung der Sperrberechtigung des Beauftragenden die Sperrung der entsprechenden C.NK.VPN-Zertifikate unverzüglich bei dem TSP X.509 nonQES (Zertifikatsaussteller) beauftragen.

    <=

    TIP1-A_5398

    Der Hersteller des Konnektors DARF NICHT die Sperrung von C.NK.VPN-Zertifikaten bei dem TSP X.509 nonQES (Zertifikatsaussteller) beauftragen, wenn er nicht durch einen für den Konnektor Sperrberechtigten dazu beauftragt wurde.

    <=

    TIP1-A_5399

    Der Hersteller des Konnektors MUSS die Durchführung der Sperrung eines Konnektors protokollieren und der gematik auf Anfrage übermitteln.
    Dabei MÜSSEN folgende Informationen protokolliert werden:

    <=

    Der Hersteller des Konnektors übernimmt im Rahmen der organisatorischen Sperrung die Aufgabe der Anwenderkommunikation gegenüber den betroffenen Anwendern. Die Eckpunkte zur Kommunikation sind Bestandteil des Beschlusses zur Außerbetriebnahme einer Konnektor-Baureihe und im Rahmen des Change-Verfahrens zwischen den Beteiligten abgestimmt.

    TIP1-A_5400

    Der Hersteller des Konnektors MUSS die Fortführung des Sperrprozesses über die Einstellung seiner Geschäftstätigkeit hinaus gewährleisten.

    <=

    Dies kann bspw. durch Übertragung der Aufgabe an einen Dritten realisiert werden. Dabei sind die Zuordnungen Konnektor zu Zertifikat gemäß Anforderung „Dokumentation der Konnektorzertifikatszuordnungen“ zur Verfügung zu stellen.

    Bei der Schlüsselerzeugung für die gSMC-K muss insbesondere auch mit technischen Maßnahmen die Vertraulichkeit der relevanten Schlüssel sichergestellt werden:

    TIP1-A_7225

    Der Hersteller des Konnektors, der Schlüssel für die gSMC-K erzeugt, MUSS diese Schlüssel mittels eines technischen Sicherheitsmoduls (HSM, Chipkarte, TPM etc.) erzeugen, welches

    1. über einen Zugriffsschutz verfügt, sodass nur Berechtigte Schlüssel darauf nutzen können,
    2. in einem zutrittsgeschützten Bereich aufbewahrt wird und
    3. mindestens nach FIPS 140-2 Level 3 oder [COS-G2] (CC-zertifizierte Chipkarte der TI) zertifiziert ist.
    Wird für die Schlüsselerzeugung eine Schlüsselableitung verwendet, so MUSS die Schlüsselableitung die fachlichen Anforderungen aus GS-A_5386 erfüllen.
    Es ist zulässig, dass asymmetrische Schlüssel bei der Personalisierung auf der gSMC-K selbst erzeugt werden und symmetrische Schlüssel mittels einer Schlüsselableitung erzeugt werden, bei dem sich der Ableitungsschlüssel (Masterkey) innerhalb eines nach 3. zulässigen Hardwaresicherheitsmoduls befindet.
    Es ist zulässig, sicherheitstechnisch geeignete Maßnahmen zur Sicherstellung der Verfügbarkeit der Ableitungsschlüssel (Masterkey) umzusetzen (bspw. Shamir Secret-Sharing-Verfahren).
    Der Hersteller des Konnektors MUSS die Schlüsselerzeugung und die Schlüsselverwaltung in einem Konzept darstellen, das die technischen und organisatorischen Maßnahmen beschreibt, die den Schutzbedarf der verarbeiteten Informationsobjekte befriedigen. Der Hersteller des Konnektors MUSS dieses Konzept der gematik zur Verfügung stellen. <=

    TIP1-A_5703

    Der Hersteller des Konnektors, der Daten für die gSMC-K erzeugt (bspw. Schlüssel), MUSS diese Daten bei der Übertragung zum Kartenpersonalisierer hinsichtlich Vertraulichkeit, Authentizität und Integrität mit einem Verfahren nach [gemSpec_Krypt] schützen.

    <=

    3.3 Bootup-Phase

    TIP1-A_4507

    Da während der Bootup-Phase des Konnektors noch nicht alle Sicherheitsmechanismen ihre Leistung erbringen können, DÜRFEN die Dienste des Konnektors während dem Bootup über physikalische Schnittstellen von außen NICHT erreichbar sein.

    <=

    TIP1-A_4508

    Der Konnektor MUSS nach Beendigung der Bootup-Phase die Initialisierung der Funktionsmerkmale durchlaufen haben. Die Startreihenfolge der Funktionsmerkmale kann unter Berücksichtigung von TIP1-A_4507 herstellerspezifisch gestaltet werden.
    Im Rahmen der Bootup-Phase MÜSSEN folgende TUCs ausgeführt werden: TUC_KON_025, TUC_KON_035, TUC_KON_272, TUC_KON_341, TUC_KON_343, TUC_KON_352 (die Reihenfolge der TUC-Ausführung ist herstellerspezifisch).
    Treten während der Bootup-Phase Fehler auf, so MUSS die Bootup-Phase, sofern möglich, abgeschlossen werden.
    Sobald die Bootup-Phase abgeschlossen ist, MUSS TUC_KON_256 „Systemereignis absetzen“ mit folgenden Parameter aufgerufen werden:
    TUC_KON_256 {
        topic = "BOOTUP/BOOTUP_COMPLETE";
        eventType = Op;
        severity = Info;
        }
    <=

    Die hier gelisteten TUCs bilden nicht die abschließende Menge der während der Bootup-Phase zu erfüllenden Anforderungen. In den einzelnen Funktionsmerkmalen werden weitere Einzelanforderungen erhoben, die als Ausführungszeitpunkt die Bootup-Phase benennen (siehe Unterkapitel „Betriebsaspekte“ der einzelnen Funktionsmerkmal-Kapiteln, sowie Kapitel 4.3 Konnektormanagement).

    3.4 Betriebszustand

    TIP1-A_4509

    Der Konnektor MUSS seinen Betriebszustand gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste über Fehlerzustände $EC erfassen.

    Tritt die in Spalte „Beschreibung“ charakterisierte Fehlersituation eines Fehlerzustandes $EC ein, wird sein Wert $EC.value = true. Sobald die Fehlersituation beendet ist, springt der Wert auf $EC.value = false. Die Fehlerzustände müssen dabei innerhalb der „max. Feststellungszeit“ (Tabellenspalte) erfasst werden. Eine maximale Feststellungszeit von einen Tag (1 day) verlangt, dass einmal am Tag der Zustand geprüft werden muss, unabhängig davon, welche TUCs aufgerufen werden. Eine maximale Feststellungszeit von 1 sec, 10 sec, 1 min und 300 sec verlangt, dass nach der Feststellung einer Fehlfunktion innerhalb eines TUCs die Zustandsänderung innerhalb der angegebenen Zeit stattfinden muss.

    Nach Abschluss des Boot-Vorgangs müssen sämtliche Fehlerzustände mit einer „max. Feststellungszeit“ von „1 day“ erfasst worden sein.

    <=

    TIP1-A_4597

    Der Konnektor MUSS zur Unterstützung von Missbrauchserkennungen für alle Operationen, die in EVT_MONITOR_OPERATIONS gelistet sind und deren Alarmwert > 0 ist, kontinuierlich folgende Aktivitäten durchlaufen:

    1. Minütlich gleitende 10-Minuten-Summe je in EVT_MONITOR_OPERATIONS gelistete Operation berechnen. Dazu gehen

      • erfolgreiche Abschlüsse der Operation mit dem OK_Val der Operation ein

      • eine fehlerhaft beendete Operation mit dem NOK_Val der Operation ein

    2. Überschreitet der gleitende 10-Minuten-Summenwert einer in EVT_MONITOR_OPERATIONS gelisteten Operation den zugehörigen Alarmwert, so setze EC_CRYPTOPERATION_ALARM auf True.

    <=

    Erklärung „Minütlich gleitende 10-Minuten-Summe“: Für die jeweilige Operation wird die Summe aller OK_Val und NOK_Val der letzten 10 Minuten gebildet. Diese Summe wird jede Minute neu berechnet.

    TIP1-A_4512-04

    Der Konnektor MUSS per Ereignisdienst TUC_KON_256 über Änderungen des Betriebszustandes (Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste) informieren.
    Der Konnektor muss dazu für jeden Fehlerzustand $EC mit Error Condition $EC.errorcondition mit verändertem Wert $EC.value den technischen Anwendungsfall TUC_KON_256 „Systemereignis absetzen“ mit folgenden Parametern aufrufen:
    TUC_KON_256 {    
        topic = "OPERATIONAL_STATE/$EC.errorcondition";
        eventType = $EC.type;
        severity = $EC.severity;
        parameters = („Value=$EC.value, $EC.parameterlist”)
    }


    Tabelle 5: TAB_KON_503 Betriebszustand_Fehlerzustandsliste

     ErrorCondition
    (siehe Hinweis 1)
     Beschreibung
    Type
    Seve
    rity
    max.
    Fest
    stell
    ungs-
    zeit
    Parameterlist
    (siehe Hinweis 2)
    EC_CardTerminal_
    Software_Out_Of_
    Date ($ctId)
    Software auf
    Kartenterminal($ctId)
    ist nicht aktuell
    Op
    Info
    1 day
    CtID=$ctId;
    Bedeutung=
    $EC.description
    EC_CardTerminal_
    gSMC-KT_Certificate_ Expires_Soon ($ctId)
    Das Zertifikat der gSMC-KT im
    Kartenterminal($ctId)
    läuft in weniger als 5 Wochen ab
    Op Info 7 days CtID=$ctId;
    Bedeutung=
    $EC.description
    EC_Connector_
    Software_Out_
    Of_Date
    I_KSRS_Download::list_
    Updates
    liefert mindestens eine
    UpdateInformation mit einer UpdateInformation/Firmware/
    FWVersion > aktuelle Version
    der Konnektorsoftware, deren
    UpdateInformation/Firmware/
    FWPriority = „Kritisch“
    Op
    Info
    1 day
    Bedeutung=
    $EC.description
    EC_FW_Update_Available
    I_KSRS_Download::list_
    Updates
    liefert mindestens eine
    UpdateInformation mit einer UpdateInformation/Firmware/
    FWVersion > aktuelle Version
    der Konnektor- oder Kartenterminalsoftware
    Op
    Info
    1 day
    Bedeutung=
    $EC.description
    EC_FW_Not_
    Valid_Status_
    Blocked
    Konnektor Firmware muss
    aktualisiert werden. Zugang zur
    TI momentan nicht erlaubt.
    Sec
    Fatal
    1 day
    Bedeutung=
    $EC.description
    EC_Time_Sync_
    Not_Successful
    der letzte
    Synchronisationsversuch
    der Systemzeit war nicht
    erfolgreich.
    Op
    Info
    1 sec
    LastSyncAttempt=
    $lastSyncAttempt
    Timestamp;
    LastSyncSuccess
    =$lastSyncSuccess
    Timestamp;
    Bedeutung=
    $EC.description
    EC_TSL_Update_
    Not_Successful
    das letzte Update der TSL
    war nicht erfolgreich.
    Op
    Info
    1 sec
    Bedeutung=
    $EC.description;
    LastUpdateTSL=
    $lastUpdateTSL
    Timestamp
    EC_TSL_Expiring
    Systemzeit t mit
    t > NextUpdate-Element der
    TSL – 7 Tage und
    t <= NextUpdate-Element
    der TSL
    Sec
    Info
    1 day
    NextUpdateTSL
    =$NextUpdate-
    Element der TSL;
    Bedeutung=
    $EC.description
    EC_BNetzA_VL_
    Update_
    Not_Successful
    Das letzte Update der
    BNetzA-VL war nicht erfolgreich
    Op
    Info
    1 sec
    LastUpdateBNetz
    AVL=
    $lastUpdateBNetz
    AVLTimestamp;
    Bedeutung=
    $EC.description
    EC_ BNetzA_VL_
    not_valid
    Systemzeit t mit
    t > NextUpdate-Element der
    BNetzA-VL
    Sec
    War
    ning
    1 day
    NextUpdateBNetz
    AVL
    =$NextUpdate-
    Element
    der BNetzA-VL;
    Bedeutung=
    $EC.description
    EC_TSL_Trust_
    Anchor_Expiring
    Gültigkeit des Vertrauensankers
    ist noch nicht abgelaufen, läuft
    aber innerhalb von 30 Tagen ab.
    Sec
    Info
    1 day
    ExpiringDateTrust
    Anchor=
    Ablaufdatum der
    Vertrauensanker
    gültigkeit;
    Bedeutung=
    $EC.description
    EC_LOG_
    OVERFLOW
    Wenn im Rahmen der Regeln
    für die rollierende Speicherung
    von Logging-Einträgen Einträge
    gelöscht werden, die nicht älter
    als SECURITY_LOG_DAYS,  LOG_DAYS bzw. FM_
    <fmName>_LOG_DAYS sind,
    tritt der Fehlerzustand ein.
    Der Fehlerzustand kann nur
    durch einen Administrator
    wieder zurückgesetzt werden.
    Unter Protokoll wird die Liste der auslösenden Protokolle angegeben.
    Op
    War
    ning
    1 sec
    Protokoll=$Protokoll;
    Bedeutung=
    $EC.description
    EC_CRL_Expiring
    Systemzeit t > NextUpdate
    der CRL – 3 Tage
    Sec
    War
    ning
    1 day
    ExpiringDateCRL=
    NextUpdate der
    CRL;
    Bedeutung=
    $EC.description
    EC_Time_Sync_
    Pending_Warning
    MGM_LU_ONLINE=Enabled und
    keine erfolgreiche
    Synchronisation
    der Systemzeit seit d Tagen und
    d > NTP_WARN_PERIOD und
    d <= NTP_GRACE_PERIOD.
    Nach einer Korrektur oder
    Bestätigung der Systemzeit
    durch einen Administrator muss
    der Konnektor wie nach einer
    erfolgreichen Zeitsynchronisation
    verfahren, d.h., der Tagezähler
    wird auf 0 zurückgesetzt.
    Sec
    War
    ning
    1 day
    LastSyncSuccess=
    $lastSyncSuccess
    Timestamp;
    Bedeutung=
    $EC.description
    EC_TSL_Out_
    Of_Date_Within_
    Grace_Period
    Systemzeit t mit
    t > NextUpdate-Element der TSL
    und
    t <= NextUpdate-Element
    der TSL + CERT_TSL_
    DEFAULT_GRACE_
    PERIOD_DAYS
    und eine neue TSL ist nicht
    verfügbar
    Sec
    War
    ning
    1 day
    NextUpdateTSL
    =$NextUpdate-
    Element der TSL;
    GracePeriodTSL
    =CERT_TSL_
    DEFAULT_
    GRACE_PERIOD_
    DAYS;
    Bedeutung=
    $EC.description
    EC_CardTerminal_
    Not_Available
    ($ctId)
    Kartenterminal($ctId) ist nicht
    verfügbar. Dieser
    Betriebszustand
    bezieht sich auf die als „aktiv“
    gekennzeichneten KTs.  
    Op
    Error
    1 sec
    CtID=$ctId;
    Bedeutung=
    $EC.description
    EC_No_VPN_TI_
    Connection
    Kein sicherer Kanal (VPN) in die Telematikinfrastruktur aufgebaut.
    Der Wert 300 sec ist abgeleitet
    aus der maximalen
    Verbindungsaufbauzeit bei
    einem Standortausfall des
    VPN-Zugangsdienstes.
    Op
    Error
    300 sec
    Bedeutung=
    $EC.description
    EC_No_VPN_
    SIS_Connection
    Kein sicherer Kanal (VPN) zu
    den Sicheren Internet Services
    aufgebaut.
    Der Wert 300 sec ist abgeleitet
    aus der maximalen
    Verbindungsaufbauzeit
    bei einem
    Standortausfall des
    VPN-Zugangsdienstes.
    Op
    Error
    300 sec
    Bedeutung=
    $EC.description
    EC_No_Online_
    Connection
    Konnektor kann Dienste im
    Transportnetz nicht erreichen.
    Op
    Error
    10 sec
    Bedeutung=
    $EC.description
    EC_IP_Adresses_
    Not_Available
    Die IP-Adressen des
    Netzkonnektors sind nicht oder
    falsch gesetzt.
    Sec
    Error
    1 sec
    Bedeutung=
    $EC.description
    EC_CRL_Out_Of_
    Date
    Systemzeit t > Next Update
    der CRL
    Sec
    Fatal
    1 day
    NextUpdateCRL=
    $NextUpdate der
    CRL;
    Bedeutung=
    $EC.description
    EC_Firewall_Not_
    Reliable
    Firewall-Regeln konnten nicht
    fehlerfrei generiert werden oder
    beim Laden der Firewall-Regeln
    ist ein Fehler aufgetreten.
    Sec
    Fatal
    1 sec
    Bedeutung=
    $EC.description
    EC_Random_
    Generator_
    Not_Reliable
    Der Zufallszahlengenerator kann
    die Anforderungen an die zu
    erzeugende Entropie
    nicht erfüllen.
    Sec
    Fatal
    1 sec
    Bedeutung=
    $EC.description
    EC_Secure_
    KeyStore_
    Not_Available
    Sicherer Zertifikats- und
    Schlüsselspeicher des
    Konnektors
    (gSMC-K oder Truststore)
    nicht verfügbar
    Sec
    Fatal
    1 sec
    Bedeutung=
    $EC.description
    EC_Security_
    Log_
    Not_Writable
    Das Sicherheitslog kann nicht
    geschrieben werden.
    Op
    Fatal
    1 sec
    Bedeutung=
    $EC.description
    EC_Software_
    Integrity_
    Check_Failed
    Eine oder mehrere
    konnektorinterne
    Integritätsprüfungen der aktiven Konnektorbestandteile
    sind fehlgeschlagen.
    Sec
    Fatal
    1 day
    Bedeutung=
    $EC.description
    EC_Time_
    Difference_
    Intolerable
    Abweichung zwischen
    der lokalen Zeit und der
    per NTP empfangenen
    Zeit bei der
    Zeitsynchronisation
    größer als NTP_MAX_
    TIMEDIFFERENCE.
    Nach einer Korrektur oder
    Bestätigung der Systemzeit
    durch einen Administrator
    muss der Konnektor den
    Fehlerzustand zurücksetzen.
    Sec
    Fatal
    1 sec
    NtpTimedifference=
    Zeitabweichung;
    NtpMaxAllowed
    Timedifference
    =NTP_MAX_
    TIMEDIFFERENCE;
    Bedeutung=
    $EC.description
    EC_Time_Sync_
    Pending_Critical
    MGM_LU_ONLINE=
    Enabled und
    keine erfolgreiche
    Synchronisation
    der Systemzeit seit d Tagen
    und
    d > NTP_GRACE_PERIOD
    Nach einer Korrektur oder
    Bestätigung der Systemzeit
    durch einen Administrator muss
    der Konnektor wie nach einer
    erfolgreichen
    Zeitsynchronisation
    verfahren, d.h., der Tagezähler
    wird auf 0 zurückgesetzt.
    Sec
    Fatal
    1 day
    LastSyncSuccess
    =$lastSync
    SuccessTimestamp;
    NtpGracePeriod=
    NTP_GRACE_
    PERIOD;
    Bedeutung=
    $EC.description
    EC_TSL_Trust_
    Anchor_
    Out_Of_Date
    Gültigkeit des Vertrauensankers
    ist abgelaufen
    Sec
    Fatal
    1 day
    ExpiringDateTrust
    Anchor=
    Ablaufdatum der
    Vertrauensanker
    gültigkeit;
    Bedeutung=
    $EC.description
    EC_TSL_Out_
    Of_Date_
    Beyond_Grace_
    Period
    Systemzeit t mit
    t > NextUpdate-Element
    der TSL +
    CERT_TSL_DEFAULT_
    GRACE_ PERIOD_DAYS
    und eine neue TSL ist
    nicht verfügbar
    Sec
    Fatal
    1 day
    NextUpdateTSL
    =$NextUpdate-
    Element der TSL;
    GracePeriodTSL
    =CERT_TSL_
    DEFAULT_
    GRACE_PERIOD_
    DAYS;
    Bedeutung=
    $EC.description
    EC_
    CRYPTOP
    ERATION_
    ALARM
    Gemäß TIP1-A_4597 wurde ein
    potentieller Missbrauch einer
    Kryptooperation erkannt.
    Nur der Administrator kann die
    Alarmmeldung zurücksetzen.
    Sec
    War
    ning
    1 min
    Operation=
    $Operationsname;
    Count=$Summenwert;
    Arbeitsplatz=
    $<Liste
    operationsaufrufenden workplaceIDs>;    
    Meldung=
    ’Auffällige Häufung von
    Operationsaufrufen
    in den
    letzten 10 Minuten’
    EC_OTHER_
    ERROR_
    STATE($no)
    Herstellerspezifische
    Fehlerzustände, die per $no
    (von 1 aufsteigend nummeriert)
    identifiziert werden.
    $Type, $Severity und
    $ParameterList legt
    der Hersteller
    nach Bedarf fest.
    $Type
    $Sev
    erity
    <= 1 day
    Bedeutung=
    $EC.description
    EC_NK_Certificate_Expiring Das C.NK.VPN-Zertifikat läuft bald ab. 
    Systemzeit t > (Ablaufdatum von C.NK.VPN – 180 Tage)
    Sec Warning 1 day Iccsn=$Iccsn;
    Serial=$Serialnumber;
    Bedeutung=
    $EC.description
    EC_NK_Certificate_Expired Das C.NK.VPN-Zertifikat ist abgelaufen.
    Systemzeit t > Ablaufdatum von C.NK.VPN 
    Sec  Fatal 1 day Iccsn=$Iccsn;
    Serial=$Serialnumber;
    Bedeutung=
    $EC.description
    EC_TLS_Client_Certificate_Security Das für die Authentifizierung gegenüber dem Clientsystem konfigurierte Zertifikat hat ein Sicherheitsniveau von weniger als 120bit. Zu verwenden ist ein RSA -Zertifikat mit mindestens 3000 bit Schlüssellänge oder ein ECC Zertifikat. Sec Info 1 day Bedeutung=
    $EC.description
    Erläuterungen zu TAB_KON_503:
    Hinweis 1:
    Jeder Fehlerzustand wird durch einen eindeutigen ErrorCondition identifiziert. Dieser kann einen Parameter enthalten. Sind etwa die Kartenterminals mit ctId=47 und das mit ctId=93 nicht erreichbar, so lauten die ErrorCondition „EC_CardTerminal_Not_Available(47)“ und „EC_CardTerminal_Not_Available(93)“.
    Hinweis 2:
    EC.description referenziert den Text, der in der Spalte „Beschreibung“ des Zustandes spezifiziert wurde.
    <=

    Unter „kartenbasiert“ sind nicht nur Lösungen mit Smartcards sondern auch solche mit HSMs (Hardware Security Modules) zu verstehen.

    A_17085

    Wenn MGM_LU_ONLINE=Enabled nicht erfüllt ist, DARF der Konnektor den Zustand EC_No_VPN_TI_Connection NICHT annehmen. <=

    A_17086

    Wenn MGM_LU_ONLINE=Enabled oder ANLW_INTERNET_MODUS=SIS nicht erfüllt ist, DARF der Konnektor den Zustand EC_No_VPN_SIS_Connection NICHT annehmen. <=

    A_17087

    Wenn MGM_LU_ONLINE=Enabled nicht erfüllt ist, DARF der Konnektor den Zustand EC_No_Online_Connection NICHT annehmen. <=

    A_22970

    Der Konnektor MUSS 180 Tage vor Ablauf des aktuell verwendeten C.NK.VPN-Zertifikats in den Zustand EC_NK_Certificate_Expiring wechseln.
    <=

    A_22971

    Der Konnektor MUSS mit dem Ablauf des aktuell verwendeten C.NK.VPN-Zertifikats in den Zustand EC_NK_Certificate_Expired wechseln.
    <=

    Tabelle 6: TAB_KON_504 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen

    EC_ Software_ Integrity_ Check_ Failed
    EC_ Random_ Generator_ Not_ Reliable
    EC_ Security_ Log_ Not_ Writable
    EC_ Time_ Sync_ Pending_ Critical
    EC_ Time_ Diffe rence_ Intoler able
    EC_ CRL_ Out_ Of_ Date
    EC_ TSL_ Out_ Of_ Date_ Beyond_ Grace_ Period
    EC_ TSL_ Trust_
    Anchor_
    Out_
    Of_
    Date
    EC_ Secure_ KeyStore_ Not_ Available
    EC_ FW_ Not_ Valid_ Status_ Blocked
    EC_
    NK_
    Certificate_
    Expired 
    Technische Use Cases (TUCs) der Basisdienste
    relevant für Fachanwendung und die Kommunikation mit Weiteren Anwendungen und SIS

    Zugriffsberechtigungsdienst
     
     
     
     
     
     
     
     
     
    TUC_KON_000 Prüfe Zugriffsberechtigung
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    Dienstverzeichnisdienst
     
     
     
     
     
     
     
     
     
     
    TUC_KON_041 Einbringen der Endpunktinformationen während der Bootup-Phase
    -
    -
    -
    x
    x
    x
    x
    x
    x
    x
    x
    Kartenterminaldienst
     
     
     
     
     
     
     
     
     
    TUC_KON_051 Mit Anwender über Kartenterminal interagieren
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    Kartendienst
     
     
     
     
     
     
     
     
     
    TUC_KON_005 Card-to-Card authentisieren
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    TUC_KON_006 Datenzugriffsaudit eGK schreiben
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    TUC_KON_018 eGK-Sperrung prüfen
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    TUC_KON_024 Karte zurücksetzen
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    TUC_kON_026 Liefere
    CardSession
    -
    -
    -
    -
    -
    x
    -
    x
    -
    -
    -
    TUC_KON_200 SendeAPDU
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    TUC_KON_202 LeseDatei
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    TUC_KON_203 SchreibeDatei
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    TUC_KON_209 LeseRecord
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    Systeminformationsdienst
    TUC_KON_256 Systemereignis absetzen
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    Verschlüsselungsdienst
     
     
     
     
     
     
     
     
     
    TUC_KON_072 Daten symmetrisch verschlüsseln
    -
    -
    -
    x
    x
    x
    x
    x
    -
    x
    -
    TUC_KON_073 Daten symmetrisch entschlüsseln
    -
    -
    -
    x
    x
    x
    x
    x
    -
    x
    -
    Zertifikatsdienst
     
     
     
     
     
     
     
     
     
     
    TUC_KON_034 Zertifikatsinformationen extrahieren
    -
    -
    -
    x
    x
    x
    x
    x
    -
    x
    x
    Protokollierungsdienst
     
     
     
     
     
     
     
     
     
    TUC_KON_271 Schreibe Protokolleintrag
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    TLS-Dienst 
     
     
     
     
     
     
     
     
     
    TUC_KON_110 Kartenbasierte TLS-Verbindung aufbauen
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    Verbindung zum VPN-Konzentrator
     
     
     
     
     
     
     
     
     
     
    TUC_VPN-ZD_0001 „IPsec Tunnel TI aufbauen”
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    TUC_VPN-ZD_0002 „IPsec Tunnel SIS aufbauen”
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    Operationen der Basisdienste
    Kartendienst
     
     
     
     
     
     
     
     
     
    VerifyPin  
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    UnblockPin  
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    ChangePin 
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    GetPinStatus  
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    Systeminformationsdienst
     
     
     
     
     
     
     
     
     
    Schnittstelle der Ereignissenke
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    GetCardTerminals
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    -
    GetCards
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    -
    GetResourceInformation
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    -
    Subscribe
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    -
    RenewSubscription
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    -
    Unsubscribe
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    -
    GetSubscription
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    -
    Verschlüsselungsdienst
     
     
     
     
     
     
     
     
     
    EncryptDocument
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    DecryptDocument
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
     Signaturdienst
     
     
     
     
     
     
     
     
     
    SignDocument
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    VerifyDocument
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    GetJobNumber
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    StopSignature
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    ActivateComfortSignature
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    DeactivateComfortSignature
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    GetSignatureMode
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    Authentifizierungsdienst   
    ExternalAuthenticate
    -
    -
    -
    -
    -
    x
    x
    x
    -
    x
    -
    Zertifikatsdienst
     
     
     
     
     
     
     
     
     
    ReadCardCertificate
    -
    -
    -
    -
    -
    x
    x
    x
    x
    x
    -
    CheckCertificateExpiration
    -
    -
    -
    -
    -
    x
    x
    x
    x
    x
    -
    VerifyCertificate
    -
    -
    -
    -
    -
    x
    -
    x
    x
    x
    -
    Zeitdienst
     
     
     
     
     
     
     
     
     
    I_NTP_Time_Information
    -
    -
    -
    -
    -
    x
    x
    x
    x
    -
    -
    Konnektormanagement
     
     
     
     
     
     
     
     
     
    Softwareaktualisierung
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    Protokolleinsicht
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    Werksreset
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x
    Sonstiges
    -
    x
    x
    x
    x
    x
    x
    x
    x
    x
    x

    In den kritischen Fehlerzuständen, in denen keine TLS-Verbindung ins LAN aufgebaut werden (EC_Random_Generator_Not_Reliable, EC_Software_Integrity_Check_Failed, EC_Security_Log_Not_Writable, EC_Time_Sync_Pending_Critical, EC_Time_Difference_Intolerable, EC_NK_Certificate_Expired), kann keine Verbindung zu den Kartenterminals aufgebaut werden. Infolge sind hier keine Kartenoperationen zugelassen.

    Wenn keine Verbindung zum VPN-Konzentrator des SIS aufgebaut werden kann, ist dadurch das Internet nicht über den Konnektor erreichbar. Wenn keine Verbindung zum VPN-Konzentrator der TI aufgebaut werden kann, sind Bestandsnetze nicht erreichbar.

    Bezüglich der Administration des Konnektors im Zustand EC_FIREWALL_NOT_RELIABLE ist eine Abstimmung mit der Prüfstelle und der Zertifizierungsstelle notwendig.

    A_16203

    Im Zustand EC_Firewall_Not_Reliable DARF der Konnektor NICHT nutzbar sein. Möglichkeiten zur Behebung des Zustandes EC_Firewall_Not_Reliable sind mit dem CC - Evaluierer und Zertifizierer abzustimmen. <=

    Die Architektur der TI ist so angelegt, dass die Fehlerzustände mit Severity=Fatal in den Tabellen TAB_KON_504 und TAB_KON_503 mit vernachlässigbarer Wahrscheinlichkeit von externen Einflüssen abhängen. Die SLAs für Dienste der zentralen TI-Plattform sind so gefasst, dass diese schwerwiegend verletzt werden müssten, um dadurch einen Konnektor in einen solchen kritischen Zustand zu bringen (externer Fehler aus Sicht des Konnektors). Dass beispielsweise der TSL-Dienst über den Zeitraum der Grace-Period-TSL (typisch: 7 Tage) nicht erreichbar ist (ErrorCondition EC_TSL_Out_Of_Date _Beyond_Grace_Period), kann nur bei massiver Verletzung der für zentrale Dienste festgelegten SLAs eintreten.

    Um die konnektorinternen Fehlerquellen zu erfassen, die dazu führen, dass ein Fehlerzustand mit Severity=Fatal eintritt oder ein anderer Zustand, in dem der Konnektor nicht verwendbar ist, wird Folgendes gefordert:

    TIP1-A_5148

    Der Konnektorhersteller MUSS den mittleren Zeitabstand zwischen Ausfällen (MTBF) als Produkteigenschaft ausweisen. Der Konnektor soll einen mittleren Zeitabstand zwischen Ausfällen (MTBF) von mindestens 50 Jahren haben.

    Ein „Ausfall gilt dann als eingetreten, wenn

    <=

    Bei einem mittleren Zeitabstand zwischen Ausfällen (MTBF) von 50 Jahren ist die Wahrscheinlichkeit, dass ein Fehlerzustand mit Severity=Fatal auftritt, kleiner 2 % pro Jahr.

    TIP1-A_4510-04

    Der Konnektor MUSS bei eingetretenem Fehlerzustand aus Tabelle Tab_ Kon_503 Betriebszustand_Fehlerzustandsliste mit Severity=Fatal dafür sorgen, dass von den Operationen der Basisdienste und Technische Use Cases (TUCs) der Basisdienste, die relevant für Fachanwendungen sind, nur erlaubte Operationen und TUCs gestartet und ausgeführt werden.
    Welche Operationen und TUCs je eingetretenem Fehlerzustand ausgeführt werden dürfen, legt Tabelle „TAB_KON_504 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen“ fest: Jede Erlaubnis ist dort durch ein „x“ definiert.
    Abweichend zu Angaben in der Tabelle TAB_KON_504 DÜRFEN folgende Operationen und TUCs NICHT im Zustand EC_Firewall_Not_Reliable ausgeführt werden:

    Sind mehrere Fehlerzustände gleichzeitig eingetreten, dürfen nur die Operationen und TUCs ausgeführt werden, die für alle eingetretenen Fehlerzustände erlaubt sind. Der Konnektor MUSS Anfragen, die auf Grund eines kritischen Fehlerzustandes nicht ausgeführt oder abgebrochen werden, mit einem Fehler (Fehlercode 4002) beantworten.

    Tabelle 7: TAB_KON_502 Fehlercodes „Betriebszustand“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4002
    Security
    Fatal
    Der Konnektor befindet sich in einem kritischen Betriebszustand

    <=

    3.4.1 Betriebsaspekte

    Der Konnektor soll per Signaleinrichtung am Konnektor die Fehlerzustände mit Severity „Error“ und „Fatal“ anzeigen (siehe [TIP1-A_4843]).

    TIP1-A_4513

    Der Konnektor MUSS es dem Administrator ermöglichen, den aktuellen Betriebszustand einzusehen und Fehlerzustände zurückzusetzen, soweit diese Möglichkeit in Tabelle „TAB_KON_503 Betriebszustand_Fehlerzustandsliste“ für den jeweiligen Fehlerzustand festgelegt ist.

    Ferner MUSS es die Managementschnittstelle dem Administrator ermöglichen, Konfigurationsänderungen gemäß Tabelle TAB_KON_505 vorzunehmen:

    Tabelle 8: TAB_KON_505 Konfigurationswerte Missbrauchserkennung

    ReferenzID

    Belegung

    Bedeutung und Administrator-Interaktion

    EVT_MONITOR_OPERATIONS

    Liste von:

    - Operationsname

    - OK_Val (Nummer)

    - NOK_Val (Nummer)

    - Alarmwert (Nummer)

    Der Administrator MUSS in der Liste der zur Missbrauchserkennung überwachbaren Operationen alle Listeneinträge einsehen können. Er MUSS den jeweiligen Alarmwert editieren können (0-9999, 0=deaktiviert).

    OK_VAL und NOK_VAL DÜRFEN durch den Administrator NICHT veränderbar sein.


    <=

    3.5 Fachliche Anbindung der Clientsysteme

    Für die Schnittstellen des Konnektors zu den Clientsystemen kann gesteuert werden:

    Dabei werden die folgenden zwei Nutzungsszenarien nicht unterschieden:

    Sowohl die Anbindung zur Administration des Konnektors, als auch die Anbindung zur Nutzung von Bestandsnetzen oder dem gesicherten Internetzugang sind nicht Gegenstand dieser Schnittstellenfestlegungen. Für die Anbindung zu Administration wird diese im Kapitel Konnektormanagement beschrieben, für die Anbindung von Bestandsnetzen bzw. dem gesicherten Internetzugang ist diese Art der Regelung nicht erforderlich, da es sich dort um Routing-Funktionen handelt.

    Die seitens des Administrators einstellbaren Werte und Listen sind, der allgemeinen Struktur dieses Dokuments folgend, im Unterkapitel 3.4.1 Betriebsaspekte beschrieben.

    TIP1-A_4514

    Der Konnektor MUSS TLS in Richtung der Clientsysteme für alle Außenschnittstellen der Basisdienste:

    unterstützen.
    Ferner MUSS der Konnektor für die SOAP-Endpunkte der Fachmodule TLS unterstützen.
    Der Konnektor MUSS sich mittels ID.AK.AUT gegenüber dem Client authentisieren.
    <=

    TIP1-A_4515

    Der Konnektor MUSS immer TLS-Verbindungsanfragen von Clientsystemen annehmen.

    Der Konnektor MUSS bei gesetzter Variable ANCL_TLS_MANDATORY = Enabled den Verbindungsversuch von Clientsystemen ohne TLS ablehnen. Ausgenommen hiervon sind Anfragen an den Dienstverzeichnisdienst bei gesetzter Variable ANCL_DVD_OPEN = Enabled.

    <=

    TIP1-A_4516

    Der Konnektor MUSS zur Client-Authentifizierung die Verfahren Basic Authentication (Username/Password) [RFC2617] über HTTP/TLS [RFC2818] und zertifikatsbasierte Client-Authentifizierung (X.509) [gemSpec_PKI#8.3.1.4] über TLS anbieten.
    Dabei MUSS für eine erfolgreiche Prüfung bei Basic Authentication:

    Für eine erfolgreiche Prüfung mit zertifikatsbasierter Client-Authentifizierung MUSS:
    Schlägt die Prüfung fehl, MUSS der Verbindungsversuch des Clientsystem abgelehnt werden. <=

    Bei der Authentisierung des Clientsystems geht es um eine Authentisierung in zwei Richtungen:

    1. Authentisierung des Clientsystems in der Rolle eines Clients gegenüber dem Konnektor für die Übertragung von SOAP-Requests.
    2. Authentisierung des Clientsystems in der Rolle eines Servers gegenüber dem Konnektor zum Empfang von CETP-Ereignismitteillungen des Systeminformationsdienstes.

    Für beide Richtungen kann das Clientsystem dasselbe Zertifikat verwenden.

    TIP1-A_5009

    Der Konnektor MUSS für Verbindungen zu Clientsystemen als Authentifizierungsmethode ausschließlich folgende Varianten erlauben:

    1. Für Verbindungen mit dem Konnektor in der Rolle des Servers (SOAP-Requests):
    1. Für Verbindungen mit dem Konnektor in der Rolle des Clients (CETP-Protokoll):
    Alle anderen Verbindungsversuche von Clientsystemen MÜSSEN vom Konnektor abgelehnt werden.
    <=

    Für die Anbindung der Clientsysteme ergeben sich verschiedene Konfigurationsvarianten bezüglich der Absicherung der Verbindungen zwischen Konnektor und Clientsystemen. Tabelle TAB_KON_852 listet die Varianten für die Verbindungen zum Aufruf der WebService-Schnittstellen (Varianten SOAP1 bis SOAP4), für die Verbindungen zum Senden von Events (Varianten CETP1 und CETP2) und für Verbindungen zum Abruf des Dienstverzeichnisses (Varianten DVD1, DVD2 und DVD3).

    Tabelle 9: TAB_KON_852 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen

    Konfigu-
    rations-
    variante
    ANCL_
    TLS_
    MAN-
    DATORY
    ANCL_
    CAUT_
    MAN-
    DATORY
    ANCL_
    CAUT_
    MODE
    ANCL_
    DVD_
    OPEN
    Bedeutung
    CETP1
    Enabled
    Irrelevant
    Irrelevant
    Irrelevant
    Der Konnektor sendet Events ausschließlich über TLS.
    Er authentisiert sich, wenn ihn das Clientsystem im Rahmen des TLS-Handshakes dazu auffordert.   
    CETP2
    Disabled
    Irrelevant
    Irrelevant
    Irrelevant
    Der Konnektor sendet Events immer über eine TCP-Verbindung ohne TLS.  
    SOAP1
    Enabled
    Enabled
    CERTIFICATE
    Irrelevant
    Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS. Der Konnektor verlangt beim TLS-Handshake die Authentisierung des Clientsystems per Zertifikat.
    SOAP2
    Enabled
    Enabled
    PASSWORD
    Irrelevant
    Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor prüft auf Anwendungsebene, dass Aufrufer sich per Username/Password  [RFC2617] authentisieren.
    SOAP3
    Enabled
    Disabled
    Irrelevant
    Irrelevant
    Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor nimmt keine Clientauthentifizierung vor.
    SOAP4
    Disabled
    Irrelevant
    Irrelevant
    Irrelevant
    Der Konnektor akzeptiert vom Clientsystem sowohl Aufrufe ohne TLS als auch über TLS. Im zweiten Fall sollte der Konnektor das Clientsystem nicht authentifizieren, wenn er es aber für den Sonderfall ANCL_CAUT_MANDATORY=Enabled aktuell tut, sehen wir das nicht als Fehler.
    DVD1
    Irrelevant
    Irrelevant
    Irrelevant
    Enabled
    Zugriff auf Dienstverzeichnisdienst kann über HTTP und HTTPS erfolgen.
    DVD2
    Enabled
    *
    *
    Disabled
    Zugriff auf Dienstverzeichnisdienst kann nur über HTTPS erfolgen.
    *) Bzgl. Clientauthentisierung wirken die Schalter wie in SOAP 1, SOAP 2, SOAP 3
    DVD3
    Disabled
    Irrelevant
    Irrelevant
    Disabled
    Zugriff auf Dienstverzeichnisdienst kann über HTTP und HTTPS erfolgen.

    Client-Authentisierung bei Nutzung des LDAP-Proxy

    Für die Nutzung des LDAP-Proxy gelten abweichende Festlegungen, da viele Standard LDAP- / Mail-Clients grundsätzlich keine Funktion zur Client-Authentisierung anbieten. Um die Nutzung des LDAP-Proxy und somit des VZD der TI dennoch zu ermöglichen, ohne dabei auf eine verpflichtende Client-Authentisierung für SOAP-Aufrufe zu verzichten, werden für LDAP gesonderte Regelungen getroffen.

    A_21224-01

    Bei der Verwendung  des LDAP-Proxies im Konnektor, MUSS sich der Konnektor abhängig von der Stellung der Schalter ANCL_TLS_MANDATORY, ANCL_CAUT_MANDATORY, ANCL_CAUT_MODE und ANCL_CAUT_LDAP gemäß der Tabelle TAB_KON_860 verhalten.

    Tabelle 10: TAB_KON_865-01 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen bei LDAP

    Konfigu-
    rations-
    variante
    ANCL_
    TLS_
    MAN-
    DATORY
    ANCL_
    CAUT_
    MAN-
    DATORY
    ANCL_
    CAUT_
    MODE
    ANCL_
    CAUT_
    LDAP
    Bedeutung
    LDAP1
    Enabled
    Enabled
    Irrelevant
    CERTIFICATE Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS. Der Konnektor verlangt beim TLS-Handshake bei Nutzung des LDAP-Proxy die Authentisierung des Clientsystems per Zertifikat.
    LDAP2
    Enabled
    Enabled
    Irrelevant
    None Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor nimmt bei Nutzung des LDAP-Proxy keine Clientauthentifizierung vor. 
    LDAP3
    Enabled
    Disabled
    Irrelevant
    Irrelevant Der Konnektor akzeptiert vom Clientsystem nur Aufrufe über TLS.  Der Konnektor nimmt keine Clientauthentifizierung vor.
    LDAP4
    Disabled
    Irrelevant
    Irrelevant
    Irrelevant Der Konnektor akzeptiert vom Clientsystem sowohl Aufrufe ohne TLS als auch über TLS. Im zweiten Fall sollte der Konnektor das Clientsystem nicht authentifizieren, wenn er es aber für den Sonderfall ANCL_CAUT_MANDATORY=Enabled, ANCL_CAUT_LDAP=CERTIFICATE aktuell tut, sehen wir das nicht als Fehler.
    <=

    Aus A_21224 resultiert direkt, dass als Client-Authentisierung für LDAPS nur Client-Zertifikate unterstützt werden müssen. Die Authentisierung mit Username/Passwort wird bei LDAPS nicht unterstützt.

    Es sei noch einmal betont, dass TIP1-A_5009 sich nur auf SOAP und CETP bezieht und TIP1-A_4516 das Basic-Authentication Verfahren nur für HTTP fordert.

    3.5.1 Betriebsaspekte

    Damit sich ein Clientsystem mittels X.509 authentisieren kann, muss es über ein entsprechendes Zertifikat verfügen. Diese Zertifikate kann der Administrator entweder mit seinen lokalen Mitteln selbst oder mittels des Konnektors erzeugen. In beiden Fällen müssen diese Zertifikate sowohl im Clientsystemen (hier zusammen mit ihren privaten Schlüsseln), als auch im Konnektor vorhanden sein.

    Da es sich um eine lokal begrenzte Authentisierung im Verantwortungsbereich des Betreibers des lokalen Netzes handelt, werden keine weiteren Vorgaben zu den Schlüsselspeichern auf Clientsystemseite erhoben. Auch hinsichtlich der außerhalb des Konnektors erzeugten Zertifikate gelten keine weiteren Vorgaben. Ferner ist eine Online-Prüfung dieser Zertifikate nicht erforderlich.

    TIP1-A_4517

    Der Konnektor MUSS die Erstellung und den Export von X.509-Zertifikaten für Clientsysteme und der zugehörigen privaten Schlüssel durch den Administrator über das Managementinterface ermöglichen. Hierbei MUSS der Konnektor dem Administrator die Möglichkeit geben, das kryptographische Verfahren RSA-2048 oder ECC-256 auszuwählen. Als Exportformat MUSS PKCS#12 verwendet werden. Die so erstellten Zertifikate werden zu ANCL_CCERT_LIST angefügt. 
    Der Konnektor MUSS dem Administrator ferner den Import von konnektorfremden X.509-Zertifikaten für Clientsysteme über das Managementinterface ermöglichen. Die so importierten Zertifikate werden zu ANCL_CCERT_LIST angefügt.
    <=

    TIP1-A_4518-02

    Der Administrator MUSS in der Managementoberfläche die in TAB_KON_506 genannten Parameter im Managementinterface konfigurieren können.
    Wird ANCL_TLS_MANDATORY auf ENABLED gewechselt, MÜSSEN alle nicht per TLS gesicherten http-Verbindungen geschlossen werden, sobald die in den Verbindungen jeweils aktuell laufenden Außenschnittstelle-Operationen abgeschlossen wurden, mit Ausnahme von http-Verbindungen zum Dienstverzeichnisdienst.
    Der Konnektor MUSS den Administrator geeignet und verständlich auf seine Verantwortung für die Sicherung der Kommunikation hinweisen.

    Tabelle 11: TAB_KON_506-01 Konfigurationsparameter der Clientsystem-Authentisierung

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    ANCL_TLS_MANDATORY
    Enabled/Disabled
    Der Administrator MUSS die verpflichtende Verwendung eines TLS gesicherten Kanals an- und abschalten können.
    Wenn ANLW_ANBINDUNGS_MODUS = Parallel MUSS der Administrator vor dem Disablen von ANCL_TLS_MANDATORY einen Warnhinweis bestätigen, der ihn über die mit der Abschaltung verbundenen Risiken informiert und darlegt, dass in diesem Fall der Nutzer die Verantwortung für die Sicherstellung der vertraulichen Übertragung übernimmt.
    Default-Wert: Enabled
    ANCL_CAUT_MANDATORY
    Enabled/Disabled
    Der Administrator MUSS die verpflichtende Authentifizierung der Clientsysteme an- und abschalten können.
    Default-Wert: Enabled
    ANCL_CAUT_MODE
    CERTIFICATE /
    PASSWORD

    Der Administrator MUSS konfigurieren können, welcher Client Authentifizierungsmodus genutzt werden kann bzw. genutzt werden muss.
    Default-Wert: CERTIFICATE
    ANCL_CAUT_LDAP Enabled/Disabled Der Administrator MUSS die verpflichtende Authentifizierung der Clientsysteme für die Nutzung des LDAP-Proxy an- und abschalten können.
    Default-Wert: Enabled
    ANCL_CCERT_LIST
    Liste von
    X.509-Zertifikaten zugeordnet zu ClientID
    Liste von importierten oder vom Konnektor erzeugten X.509-Zertifikaten und dazugehörenden Clientsystem IDs. Der Administrator MUSS die Liste der Zertifikate und den zugehörenden Clientsystemen verwalten können, der Inhalt der Zertifikate MUSS menschlich lesbar dargestellt werden.
    Es muss für den Administrator erkennbar sein, welches kryptographische Verfahren (RSA-2048 oder ECC -256) dem jeweiligen Zertifikat zugrunde liegt.

    ANCL_CUP_LIST
    Liste von Benutzer/Passwort Kombinationen, zugeordnet zu ClientID
    Liste von UserCredentials und dazugehörenden Clientsystem IDs. Der Administrator MUSS eine Liste von Credentials und zugehörendem Clientsystem verwalten können. Bei diesen Benutzer-/Passwortkombinationen handelt es sich nicht um personenbezogene Credentials, sondern um clientbezogene.
    ANCL_DVD_OPEN
    Enabled/Disabled
    Der Administrator MUSS konfigurieren können, ob der Zugriff auf den Dienstverzeichnisdienst auch dann über einen ungesicherten http-Kanal erfolgen kann (ENABLED), wenn ANCL_TLS_MANDATORY = ENABLED ist.
    Default-Wert: Enabled

    <=

    Damit sich der Konnektor mittels X.509 gegenüber Clientsystemen authentisieren kann, muss er über ein entsprechendes Zertifikat und dazu passendes Schlüsselmaterial verfügen. Dieses Zertifikat und Schlüsselmaterial befinden sich auf der gSMC-K (ID.AK.AUT). Der Administrator hat neben der Konfiguration zur Nutzung des erneuerten C.AK.AUT , welches vom Konnektor heruntergeladen wurde, auch mehrere Möglichkeiten, die ID.AK.AUT von der gSMC-K für die Authentisierung gegenüber den Clientsystemen zu ersetzen:

    Da es sich um eine lokal begrenzte Authentisierung im Verantwortungsbereich des Betreibers des lokalen Netzes handelt, werden keine weiteren Vorgaben zur Erstellung und Handhabung in der LE-Umgebung der außerhalb des Konnektors erzeugten Zertifikate und Schlüssel erhoben. Eine Online-Status-Prüfung dieser Zertifikate ist nicht erforderlich und nicht vorgesehen.

    A_21811-01

    Der Konnektor MUSS bezüglich selbst generierter und importierter Schlüssel und Zertifikate für die TLS-Authentisierung gegenüber Primärsystemen die kryptographischen Vorgaben aus gemSpec_Krypt durchsetzen und bezüglich ECC sowohl Brainpool- als auch NIST-Kurven unterstützen.
    <=

    A_21697

    Der Konnektor MUSS dem Administrator den Import eines extern generierten Schlüsselpaars und des dazugehörigen X.509-Zertifikats für die Authentisierung des Konnektors im Rahmen von TLS-Verbindungen gegenüber Clientsystemen über das Managementinterface ermöglichen. <=

    A_21698

    Der Konnektor MUSS dem Administrator das Einschalten der Verwendung von importiertem Schlüsselpaar und dazugehörigem X.509-Zertifikat für die Authentisierung des Konnektors gegenüber Clientsystemen über das Managementinterface ermöglichen. <=

    A_21699-01

    Der Konnektor MUSS die Erstellung eines Schlüsselpaars und eines dazugehörigen X.509-Zertifikats für die Authentisierung des Konnektors im Rahmen von TLS-Verbindungen gegenüber den Clientsystemen durch den Administrator über das Managementinterface ermöglichen. Hierbei MUSS der Konnektor dem Administrator die Möglichkeit geben, das kryptographische Verfahren RSA-2048, RSA-3072 oder ECC-256 auszuwählen. Ferner MUSS der Konnektor dem Administrator die Möglichkeit geben, den Hostnamen des Konnektors im Zertifikat zu vergeben.
    <=

    A_21701

    Der Konnektor MUSS dem Administrator den Export von intern generierten X.509-Zertifikaten, die für die Authentisierung des Konnektors im Rahmen von TLS-Verbindungen gegenüber den Clientsystemen verwendet werden,  über das Managementinterface ermöglichen. Der private Schlüssel verbleibt im Konnektor. <=

    A_21702

    Der Konnektor MUSS dem Administrator das Einschalten der Verwendung von intern generierten Schlüsseln und X.509-Zertifikaten für die Authentisierung des Konnektors gegenüber den Clientsystemen über das Managementinterface ermöglichen. <=

    A_21760-01

    Der Konnektor MUSS dem Administrator das Einschalten der Verwendung von ID.AK.AUT auf der gSMC-K für die Authentisierung des Konnektors gegenüber den Clientsystemen über das Managementinterface ermöglichen. Der Konnektor MUSS dabei zur Auswahl das RSA-Zertifikat C.AK.AUT.R2048 und (falls personalisiert) das ECC-Zertifikat C.AK.AUT2.XXXX anbieten. Das ausgewählte Zertifikat MUSS sowohl für die Serveridentität an der SOAP-Schnittstelle als auch für die Clientidentität an der CETP-Schnittstelle verwendet werden.
    <=

    A_22894

    Der Hersteller des Konnektors MUSS im Administratorhandbuch erläutern, welche Abhängigkeiten die unterschiedlichen Konfigurationen zur Authentifizierung gegenüber den Clientsystemen zu beachten sind.  <=

    3.6 Clientsystemschnittstelle

    TIP1-A_5401

    Alle Schnittstellen, die der Konnektor den Clientsystemen zur Verfügung stellt, MÜSSEN parallel durch mehrere Aufrufer nutzbar sein.
    <=

    3.6.1 SOAP-Schnittstelle

    Für die Beschreibung der SOAP-Schnittstelle zum Clientsystem wird in dieser Spezifikation WSDL Version 1.1 [WSDL1.1] eingesetzt. Die Interoperabilität zwischen verschiedenen SOAP-Implementierungen wird durch die Vorgaben des WS-I Basic Profile erreicht.

    A_15601

    Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Basisdienste [SOAP1.1] verwenden. <=

    TIP1-A_4519

    Der Konnektor MUSS die für die Clientsystemschnittstelle definierten Web-Services konform zu [BasicProfile1.2] anbieten.
    Abweichend von R1012 in [BasicProfile1.2] MUSS der Konnektor nur das Character Encoding UTF-8 unterstützen. Andere Kodierungen MUSS der Konnektor mit einem Fehler beantworten.
    <=

    TIP1-A_4519-01

    Der Konnektor MUSS die für die Clientsystemschnittstelle definierten Web-Services der Basisdienste konform zu [BasicProfile1.2] anbieten.
    <=

    A_15606

    Abweichend von R1012 in [BasicProfile1.2] und [BasicProfile2.0] MUSS der Konnektor nur das Character Encoding UTF-8 unterstützen. Andere Kodierungen MUSS der Konnektor mit einem Fehler beantworten.

    <=

    Da der Konnektor UTF-16 nicht unterstützt, muss das Clientsystem den Request in UTF-8 kodieren. Diese Festlegungen gelten nur für die eigentliche SOAP-Nachricht. Sind in der SOAP-Nachricht base64-encodierte XML-Elemente vorhanden, so können diese XML-Elemente andere Zeichencodierungen aufweisen.

    Fachmodule

    Fachmodule können für Web-Services, die Clientsystemen bereitgestellt werden, entweder [SOAP1.1] mit [BasicProfile1.2] oder [SOAP1.2] mit [BasicProfile2.0] verwenden. Die genaue Ausprägung erfolgt in der jeweiligen Interfacebeschreibung des Web-Services für das Fachmodul.

    A_15607

    Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Fachmodule [SOAP1.1] und [SOAP1.2] unterstützen. Die SOAP-Version pro Web-Service Endpunkt wird durch die WSDL des jeweiligen Web-Service definiert. <=

    A_15608

    Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Fachmodule bei [SOAP1.1] die Profilierung konform zu [BasicProfile1.2] anbieten. <=

    A_15609

    Der Konnektor MUSS für die an der Clientsystemschnittstelle definierten Web-Services der Fachmodule bei [SOAP1.2] die Profilierung konform zu [BasicProfile2.0]  anbieten. <=

    3.6.2 Statusrückmeldung und Fehlerbehandlung

    Der Konnektor bietet Operationen an der Außenschnittstelle über SOAP-Webservices an. Treten bei der Ausführung einer Operation Fehler auf, so werden diese an das aufrufende System gemeldet. Die von den Basisdiensten des Konnektors angebotenen SOAP-Webservices melden Fehler, die bei der Ausführung einer Operation auftreten, über eine SOAP-Fault-Nachricht (siehe auch [gemSpec_OM#3.2.3]).

    TIP1-A_5058

    Der Konnektor MUSS Fehlermeldungen, die im Rahmen einer über die Außenschnittstelle aufgerufenen Operation auftreten, an das Clientsystem mittels gematik-SOAP-Faults melden.
    <=

    TIP1-A_5058-01

    Der Konnektor MUSS Fehlermeldungen, die im Rahmen einer über die Außenschnittstelle aufgerufenen Operation eines Basisdienst-SOAP-Webservices auftreten, an das Clientsystem mittels gematik-SOAP-Faults melden.
    <=

    Treten bei konnektorinternen Operationen (TUCs) Fehler auf, so werden diese an den Aufrufer (aufrufender TUC oder aufrufende Operation) zurückgegeben. Der Aufrufer kann den aufgetretenen Fehler in seinem Kontext neu interpretieren. Das bedeutet insbesondere, dass ein Error eines aufgerufenen TUCs nicht zwingend zum Abbruch des aufrufenden TUCs bzw. der aufrufenden Operation führen muss. So ist es dem Aufrufer möglich, einen Error als Warnung zu interpretieren und an den eigenen internen oder externen Aufrufer zurückzumelden. Diese dabei erzeugte Fehlerkette wird in Form einer Fehler-Trace-Struktur abgebildet, um eine Nachverfolgung von Fehlern zu ermöglichen.

    Operationen an der Außenschnittstelle können die Fehlerkette zu Informationszwecken in der SOAP-Antwort an das Clientsystem senden. Dazu enthält jede SOAP-Antwort das Element Status, dass gemäß dem XML-Schema [ConnectorCommon.xsd] aufgebaut ist (siehe auch Abbildung PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort).



    Abbildung 3: PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort

    Schlägt eine Operation fehl, so wird eine SOAP-Fault-Meldung an das Clientsystem versendet. Im Erfolgsfall wird das Status-Element in die Antwortnachricht an das Clientsystem aufgenommen. Ist der Fehler-Trace leer (Element GERROR:Error ist nicht vorhanden), so wird CONN:Result auf OK gesetzt. Andernfalls, d. h. wenn in GERROR:Trace Fehler der Schwere Info oder Warning (zu Informationszwecken) enthalten sind, wird CONN:Result auf Warning gesetzt.

    TIP1-A_4521

    Der Konnektor MUSS Fehler protokollieren, die in fachlichen und technischen Abläufen von der gematik spezifiziert oder herstellerspezifisch definiert sind und den Schweregrad (Severity) Warning, Error oder Fatal haben. Zur Nachvollziehbarkeit des Fehlers MÜSSEN Fehlerursache, fachliche und technische Auslöser des Fehlverhaltens aus den Protokolleinträgen erkennbar sein. 
    <=

    A_14159

    Der Konnektor MUSS bei der Rückgabe von Fehlermeldungen an der Außenschnittstelle sicherstellen, dass im letzten“ GERROR:Trace“-Element der GERROR-Struktur ein von der gematik spezifizierter Fehler steht. Die GERROR-Struktur kann weitere gematik- und herstellerspezifische Fehler enthalten.
    <=

    In der Regel ist es ausreichend, wenn die GERROR-Struktur an der Außenschnittstelle nur ein Element „GERROR:Trace“ mit einem gematik-Fehler enthält.

    Wenn für eine Fehlersituation kein Fehlercode spezifiziert ist, kann ein herstellerspezifischer Fehler zur Detaillierung verwendet werden. In diesem Fall muss ein passender gematik-Fehler als letztes GERROR:Trace-Element gewählt werden.  Bei Fehlern in technischen Abläufen kann Fehlercode 4001 als letztes GERROR:Trace-Element verwendet werden. Die Wahl des letzten GERROR:Trace-Elements ist mit der gematik abzustimmen.

    Zur Struktur von Fehlermeldungen siehe auch [gemSpec_OM#GS-A_3856-*].

    3.6.3 Transport großer Dokumente

    SOAP Message Transmission Optimization Mechanism (MTOM) ermöglicht den direkten Transport von binären Daten in Webservices, d.h. ohne dass eine zur Laufzeit aufwändige Verpackung der binären Daten in ein Base64-XML-Element notwendig wird. Auf die Definition der Webservices und ihre Funktionalität hat dieser Optimierungsmechanismus keinen Einfluss. Der Einsatz von MTOM dient der Verbesserung des Performance-Verhaltens für große Dokumente.

    Das Clientsystem kann die Optimierung des Transports großer Dokumente per SOAP Message Transmission Optimization Mechanism (MTOM) anstoßen. In den WSDL-Dateien werden keine MTOM Serialization Policy Assertion [WS-MTOMPolicy] eingebettet.

    TIP1-A_5694

    Der Konnektor KANN SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM] unterstützen.
    Wenn der Konnektor MTOM unterstützt, MUSS er MTOM für Signatur- und Verschlüsselungsdienst unterstützen, DARF aber NICHT MTOM für andere Dienste unterstützen.
    Wenn der Konnektor MTOM unterstützt, MUSS er, vergleichbar dem Einsatz des Attributs wsp:Optional="true" einer MTOM Serialization Policy Assertion [WS-MTOMPolicy], genau dann MTOM für die Antwortnachricht verwenden, wenn entweder
    <=

    TIP1-A_5694-02

    Der Konnektor KANN SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM-SOAP1.1] für Basisdienste unterstützen. <=

    TIP1-A_5694-03

    Der Konnektor MUSS SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM-SOAP1.1] für Basisdienste unterstützen.
    <=

    A_15786

    Wenn der Konnektor MTOM für Basisdienste unterstützt, MUSS er MTOM für Signatur- und Verschlüsselungsdienst unterstützen, DARF aber NICHT MTOM für andere Dienste unterstützen. <=

    A_15610

    Wenn der Konnektor MTOM unterstützt, MUSS er, vergleichbar dem Einsatz des Attributs wsp:Optional="true" einer MTOM Serialization Policy Assertion [WS-MTOMPolicy], genau dann MTOM für die Antwortnachricht verwenden, wenn entweder

    <=

    A_15611

    Der Konnektor MUSS SOAP Message Transmission Optimization Mechanism (MTOM) gemäß [MTOM] für Fachmodule unterstützen, wenn es in der Schnittstellenbeschreibung des Fachmodules explizit gefordert wird. <=

    3.7 Verwendung manuell importierter CA-Zertifikate

    TI-fremde X.509-Zertifikate werden im Rahmen des Verschlüsselungsdienstes verwendet. Um den Vertrauensraum für diese Zertifikate abzubilden, erlaubt der Konnektor, X.509-CA-Zertifikate zu diesen TI-fremden X.509-Zertifikaten in eine interne Liste (CERT_IMPORTED_CA_LIST) zu importieren.

    Der Konnektor kann dann im Rahmen der Hybridverschlüsselung den symmetrischen Schlüssel empfängerspezifisch mit dessem TI-fremden X.509-Zertifikat verschlüsseln. Die TI-fremden Zertifikate dürfen nicht zu einem anderen Zweck als diesem eingesetzt werden.

    TIP1-A_5433

    Der Konnektor DARF End-Entity-Zertifikate, die lediglich gegen manuell importierte X.509-CA-Zertifikate geprüft werden, die von CAs außerhalb der TI stammen (CERT_IMPORTED_CA_LIST), NICHT für andere Zwecke als zur hybriden Verschlüsselung von Dokumenten verwenden.

    <=

    Die Berücksichtigung der CA-Zertifikate aus CERT_IMPORTED_CA_LIST muss auf folgende Anwendungsfälle beschränkt werden:

    1. Prüfung eines Zertifikates im Rahmen der hybriden Verschlüsselung

    2. Prüfung eines Zertifikates im Rahmen eines Aufrufes der Operation "VerifyCertificate"

    TIP1-A_5660

    Das Handbuch des Konnektors MUSS sinngemäß folgende Hinweise enthalten:

    <=

    3.8 Testunterstützung

    Gemäß Testkonzept der TI [gemKPT_Test#TIP1-A_6526] muss ein Hersteller eines Konnektors seine Modelle in verschiedenen Ausführungen vorsehen: für Testumgebung, für die Referenzumgebung und für die Produktivumgebung.
    Damit trotz dieser Forderung die Firmware je Konnektorversion für alle Umgebungen identisch ist, wird die Erkennung der Umgebung an die gSMC-K gebunden. Die Konnektor-Firmware muss zwischen den Umgebungen PU und RU/TU unterscheiden. Die gSMC-K besitzt hierzu den Datencontainer MF/EF.EnvironmentSettings, der die jeweilige Umgebungskennung enthält (PU bzw. TU/RU). Die Umgebungskennung wird read-only auf der gSMC-K gespeichert.

    TIP1-A_4981

    Der Produkttyp Konnektor MUSS sowohl in der Testumgebung (TU), der Referenzumgebung (RU) wie auch der Produktivumgebung (PU) betreibbar sein.
    Die Information, ob eine Konnektorinstanz in der TU/RU oder PU betrieben wird, MUSS der Konnektor dem File MF/EF.EnvironmentSettings der gSMC-K entnehmen.
    Abhängig von der ermittelten Betriebsumgebung MÜSSEN die Konfigurationswerte gemäß Tabelle TAB_KON_812 verwendet werden.

    Tabelle 12: TAB_KON_812 Umgebungsabhängige Konfigurationsparameter

    Betriebs
    umgebung
    Konfigurations
    parameter
    Konfigurations
    wert
    Beschreibung
    PU
    NET_TI_
    ZENTRAL
    siehe [gemSpec_Net#Tab_
    Adrkonzept_Produktiv]
    Siehe TAB_KON_680.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein.
    NET_TI_
    GESICHERTE_FD
    siehe [gemSpec_Net#Tab_
    Adrkonzept_Produktiv]
    Siehe TAB_KON_680.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein.
    NET_TI_
    OFFENE_FD
    siehe [gemSpec_Net#Tab_
    Adrkonzept_Produktiv]
    Siehe TAB_KON_680.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein.
    DNS_TOP_
    LEVEL_DOMAIN_TI
    telematik.
    Siehe TAB_KON_731.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, DARF aber NICHT änderbar sein.
    RU/TU
    NET_TI_
    ZENTRAL
    siehe [gemSpec_Net# Tab_Adrkonzept_Test]
    Siehe TAB_KON_680.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle mit dem Konfigurationswert voreingestellt und änderbar sein.
    NET_TI_
    GESICHERTE_FD
    siehe [gemSpec_Net# Tab_Adrkonzept_Test]
    Siehe TAB_KON_680.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle mit dem Konfigurationswert voreingestellt und änderbar sein.
    NET_TI_
    OFFENE_FD
    siehe [gemSpec_Net# Tab_Adrkonzept_Test]
    Siehe TAB_KON_680.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle mit dem Konfigurationswert voreingestellt und änderbar sein.
    DNS_TOP_
    LEVEL_
    DOMAIN_TI
    telematik-test.
    Siehe TAB_KON_731.
    Dieser Wert MUSS für den Administrator über die Managementschnittstelle einsehbar, aber nicht änderbar sein.
    <=

    TIP1-A_4707

    Der Produkttyp Konnektor MUSS auch in der Test- und Referenzumgebung betrieben werden können. Dafür MUSS der Vertrauensanker des Konnektors für diese Umgebung ausgetauscht werden können. Dies KANN durch Lieferung eines neuen Konnektors oder durch Austausch der gSMC-K durch den Hersteller ermöglicht werden. Der Hersteller MUSS sicherstellen, dass Konnektoren ausschließlich mit den zu ihrer Einsatzumgebung gehörenden Vertrauensankern ausgestattet werden.

    <=

    TIP1-A_4982

    Die Administrationsoberfläche MUSS, wenn der Konnektor in der Testumgebung (TU) oder Referenzumgebung (RU) betrieben wird, die Umgebungsbezeichnung zu jeder Zeit erkennbar in der Managementschnittstelle anzeigen.

    Die Anzeige eines Betriebs in der Produktivumgebung DARF NICHT explizit angezeigt werden.

    <=

    4 Funktionsmerkmale

    Für die folgenden Inhalte bitte die Hinweise in Kapitel 1.5.3 „Erläuterungen zur Spezifikation des Außenverhaltens„ sowie Kapitel 1.5.4 Erläuterungen zur Dokumentenstruktur und „Dokumentenmechanismen“ beachten.

    4.1 Anwendungskonnektor

    4.1.1 Zugriffsberechtigungsdienst

    Der Zugriffsberechtigungsdienst ist ein interner Dienst. Er ermöglicht es Operationen eine Prüfung auf Zugriffsberechtigung für die von ihnen benötigten Ressourcen durchzuführen. Die Prüfung erfolgt direkt nach Aufruf einer Operation des Konnektors durch das Clientsystem und basiert auf den im Clientaufruf enthaltenen Parametern.

    Der Zugriffsberechtigungsdienst definiert über ein Informationsmodell die erlaubten Zugriffsmöglichkeiten. Um dies zu erreichen, modelliert es Mandanten und ordnet ihnen Clientsysteme sowie die vom Konnektor verwalteten externen Ressourcen (Kartenterminal mit Slots, Arbeitsplatz mit SMC-Bs) zu. Diese durch einen Administrator persistent zu modellierenden Entitäten und Beziehungen beinhalten die erlaubten Zugriffswege vom Clientsystem über Arbeitsplatz zum Kartenterminal und dessen Slots. Sie werden im Konnektor administrativ konfiguriert.

    Neben diesen persistenten Entitäten und Beziehungen bildet das Modell auch die in den Slots temporär gesteckten Karten und die zugehörigen Kartensitzungen als transiente Entitäten und Beziehungen ab.

    Abbildung PIC_Kon_100 stellt das Informationsmodell dar. Die persistenten Entitäten haben einen grünen Hintergrund, die transienten einen weißen.

    Tabelle TAB_KON_507 beschreibt die Entitäten und legt ihren Identitätsschlüssel fest. Tabelle TAB_KON_508 beschreibt die Attribute. Tabelle TAB_KON_509 beschreibt die Entitätsbeziehungen und referenziert dabei die in Abbildung PIC_Kon_100 durch Zahlen in eckigen Klammern markierten Beziehungen. Tabelle TAB_KON_510 definiert Constraints, die zusätzlich zu den in Abbildung PIC_Kon_100 definierten Kardinalitäten gelten. Die Constraints werden mittels Object Constraint Language (OCL) definiert.

    4.1.1.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4522

    Der Konnektor MUSS die Entitäten, Attribute und Beziehungen des Informationsmodells intern vorhalten, dabei für die Einhaltung der definierten Constraints sorgen und die persistenten Entitäten und Beziehungen dauerhaft speichern. Der Konnektor MUSS dabei eine Mindestanzahl von 999 Mandanten unterstützen.

    Das Informationsmodell ist definiert durch das UML-Diagramm „PIC_Kon_100 Informationsmodell des Konnektors„ und die Tabelle „TAB_KON_510 Informationsmodell Constraints. Der Konnektor darf nur Daten in sein Informationsmodell übernehmen, die alle Eigenschaften des Informationsmodells, insbesondere die Constraints, erfüllen.

    Die Entitäten werden in Tabelle „TAB_KON_507 Informationsmodell Entitäten beschrieben, die Attribute in Tabelle „TAB_KON_508 Informationsmodell Attribute und die Beziehungen in Tabelle „TAB_KON_509 Informationsmodell Entitätenbeziehungen.

    <=

    Hinweis zu den Bezeichnern der Entitäten und ihrer Attribute: Im Folgenden beginnen Entitäten mit einem Großbuchstaben, Attribute mit einem Kleinbuchstaben. Werden die Entitäten und Attribute in XML-Dokumenten verwendet, so beginnen die zugeordneten XML-Elementbezeichner grundsätzlich mit einem Großbuchstaben und verwenden den englischen Begriff, der im Folgenden in Klammern angegeben ist, wenn zur besseren Lesbarkeit im Modell ein deutscher Begriff verwendet wird.



    Abbildung 4: PIC_Kon_100 Informationsmodell des Konnektors

    Tabelle 13: TAB_KON_507 Informationsmodell Entitäten

    Entität
    persistent/
    transient
    Identitätsschlüssel
    Beschreibung
    Mandant
    persistent
    mandantId
    Zu Mandanten und Mandantenfähigkeit siehe Kapitel Mandantenfähigkeit.
    Clientsystem
    persistent
    clientSystemId
    Unter einem Clientsystem wird hier ein einzelnes oder eine Gruppe von Systemen verstanden, welche im LAN der Einsatzumgebung auf die Clientsystem-Schnittstelle des Konnektors zugreifen.
    CS-AuthMerkmal
    (CS-AuthProperty)
    persistent
    csAuthId
    Das Authentifizierungsmerkmal dient der Authentifizierung, wenn sich das Clientsystem gegenüber dem Konnektor authentisiert. Der Identitätsschlüssel csAuthId wird bei der Administration vergeben
    Arbeitsplatz
    (Workplace)
    persistent
    workplaceId
    alle dem Konnektor bekannten Arbeitsplätze
    Kartenterminal
    (CardTerminal)
    persistent
    ctId
    alle dem Konnektor bekannten Kartenterminals.
    KT-Slot
    (CT-Slot)
    persistent
    ctId,
    slotNo
    Die sich in den Kartenterminals befindenden Chipkartenslots (Functional Unit Type 00)
    Karte
    (Card)
    transient
    cardHandle
    oder
    iccsn
    Die in den Kartenterminals steckenden Smartcards des Gesundheitswesens, die persönliche Identitäten oder Rollen repräsentieren (eGK, HBA, SMC-B).
    Karten, die nur Geräteidentitäten tragen (gSMC-K, gSMC-KT) werden in diesem Modell nicht betrachtet.
    Karten im Sinne dieses Informationsmodells existieren maximal so lange, wie sie im Kartenterminal stecken. Die aktuell im System steckenden Karten werden vom Clientsystem über das cardHandle adressiert. Die iccsn erlaubt eine dauerhafte Adressierung einer Karte.
    Für den Kartentyp „SM-B“ kann hier auch eine in einem HSM-B enthaltene virtuelle SMC-B abgebildet werden.
    Kartensitzung
    (CardSession)
    transient
    siehe
    konkrete
    Kartensitzungen
    Kartensitzungen stellen ein wesentliches Konzept im Sicherheitsmodell des Konnektors dar. Eine Kartensitzung verwaltet einen aktuellen logischen Sicherheitsstatus einer Karte. Die Kartensitzungen sind einer Karte fest zugewiesen.
    Zu einer Karte kann es mehrere Kartensitzungen geben, die voneinander logisch unabhängige Sicherheitsstatus einer Karte verwalten.
    Der Konnektor führt alle Zugriffe auf eine Karte im Kontext einer Kartensitzung zu dieser Karte aus.
    Das Attribut logischerKanal bezeichnet den logischen Kanal zur Karte, der im Rahmen der Kartensitzung verwendet wird (gemäß Standard [7816–4]).
    Kartensitzung_eGK
    (CardSession_eGK)
    transient
    cardHandle
    Kartensitzung für eine eGK. Die KVK ist im Modell nicht explizit dargestellt. Soweit anwendbar, gelten für die KVK die gleichen Aussagen wie für die eGK.
    Kartensitzung_SM-B
    (CardSession_SM-B)
    transient
    cardHandle, mandantId
    Kartensitzung für eine SM-B
    Kartensitzung_HBAx
    (CardSession_HBAx)
    transient
    cardHandle, clientSystemId,
    userId
    Kartensitzung für einen HBAx.
    Unter dem Typ „HBAx“ sind auch die Vorläuferkarten wie „HBA-qSig” und „ZOD_2.0“ inkludiert.
    SM-B_Verwaltet
    (SM-B_managed)
    persistent
    iccsn
    SM-Bs müssen im Gegensatz zu den übrigen Karten im Konnektor vor ihrer Verwendung persistent im Informationsmodell als
    „SM-B_Verwaltet“ per Administration aufgenommen werden.
    Dies gilt auch für die in einem HSM-B enthaltenen virtuellen SMC-Bs.
    CS_AP
    persistent
    mandantId, clientSystemId, workplaceId
    CS_AP legt die von einem Clientsystem pro Mandanten nutzbaren Arbeitsplätze fest. Ein Clientsystem kann dabei mehrere Arbeitsplätze bedienen. Ebenso können Arbeitsplätze von mehreren Clientsystemen, auch gleichzeitig, genutzt werden, z. B. bei zwei unterschiedlichen, voneinander unabhängigen Praxisprogrammen.
    Remote-PIN-KT
    persistent
    mandantId, workplaceId, ctId
    Remote-PIN-KT legt pro Mandant und Arbeitsplatz fest, über welches Kartenterminal eine Remote PIN-Eingabe erfolgen soll, wenn an diesem Arbeitsplatz die PIN-Eingabe für eine Karte erforderlich ist, die nicht in einem dem Arbeitsplatz lokal zugeordneten Kartenterminal steckt.
    AuthState
    transient
    cardHandle, (clientSystemId),
    (userId),
    ref
    Zu einer Kartensitzung gibt es höhere AuthorizationStates, die durch (type =C2C) Freischaltung oder durch PIN-Eingabe (type=CHV) erreicht werden können.
    Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.


    Tabelle 14: TAB_KON_508 Informationsmodell Attribute

    Attribut
    Beschreibung
    cardHandle
    Das Identifikationsmerkmal einer Karte für die Dauer eines Steckzyklusses. Es wird mit dem Entfernen der Karte aus dem Kartenterminal ungültig. Es wird automatisch vom Konnektor vergeben.
    clientSystemId
    Das Identifikationsmerkmal eines Clientsystems. Es wird per Administration dem Mandanten im Clientsystem und im Konnektor zugeordnet.
    csAuthId
    Das Identifikationsmerkmal eines Authentifizierungsmerkmals.
    ctId
    Das Identifikationsmerkmal eines Terminals. Es ist eine fixe Eigenschaft des Kartenterminals.
    iccsn
    Die Seriennummer einer Karte. Sie identifiziert eine Karte dauerhaft.
    isHSM
    Attribut der Entitäten Karte und SM-B_Verwaltet. Es ist false, wenn eine echte Smardcard abgebildet wird und true, wenn es sich um eine virtuelle SMC-B handelt, die in einem HSM-B enthalten ist.
    isPhysical
    Attribut des Kartenterminals das den Wert „Ja“ hat, wenn es sich um ein tatsächlich existierendes Kartenterminal handelt. Ist der Wert „Nein“, dann handelt es sich um ein logisches Kartenterminal im Zusammenhang mit einem HSM-B.
    logicalChannel
    Referenz auf ein Objekt, das einen logischen Kanal repräsentiert.
    mandantId
    Das Identifikationsmerkmal eines Mandanten. Es wird per Administration dem Mandanten im Clientsystem und im Konnektor zugeordnet.
    ref
    Das Identifikationsmerkmal eines AuthState zu einer gegebenen Kartensitzung. Im Falle C2C handelt es sich um die KeyRef (mit einer bestimmten Rolle) und in Falle CHV um eine referenzierte PIN.
    slotNo
    Das Identifikationsmerkmal eines Slot für ein bestimmtes Kartenterminal. Diese fortlaufende Nummer ist eine fixe Eigenschaft des Kartenterminals. Sie beginnt bei 1.
    type
    Als Kartenattribut: Typ einer Karte. Im Folgenden berücksichtigte Werte: „HBAx“, „SM-B“, „EGK“.
    Als Attribute eines AuthState: Typ des AuthState. „C2C“ steht für gegenseitige Kartenauthentisierung. „CHV“ steht für Card Holder Verification per PIN-Eingabe.
    userId
    Das Identifikationsmerkmal des Nutzers im Clientsystem (Die userId wird durch das Clientsystem vergeben und verwaltet).
    Die userId wird im Kontext eine Kartensitzung_HBAx vom Konnektor verwendet, um als Bestandteil des Identitätsschlüssels die Kartensitzung_HBAx zu identifizieren.
    workplaceId
    Das Identifikationsmerkmal eines Arbeitsplatzes. Es wird per Administration dem Mandanten im Clientsystem und im Konnektor zugeordnet.

    Tabelle 15: TAB_KON_509 Informationsmodell Entitätenbeziehungen

    Entitätenbeziehung
    persistent/
    transient
    Beschreibung
    Authentifikationsmerkmale des Clientsystems [1]
    persistent
    Diese Relation legt für jedes Clientsystem eine Menge von Authentisierungsmerkmalen fest. Mit einem dieser Authentisierungsmerkmale muss sich ein Client gegenüber dem Konnektor authentisiert haben, um als das entsprechende Clientsystem vom Konnektor akzeptiert zu werden.
    Clientsysteme des Mandanten [2]
    persistent
    Diese Relation weist Clientsystemen Mandanten zu.
    Arbeitsplätze des Mandanten [3]
    persistent
    Diese Relation weist Arbeitsplätze Mandanten zu.
    Arbeitsplätze können von mehreren Mandanten genutzt werden. Z. B. kann ein von mehreren Mandanten genutzter gemeinsamer Empfang als ein Arbeitsplatz modelliert werden.
    Kartenterminals des Mandanten [5]
    persistent
    Diese Relation weist Kartenterminals Mandanten zu.
    Lokale Kartenterminals [6]
    persistent
    Diese Relation erfasst die Kartenterminals, die sich lokal an einem Arbeitsplatz befinden und von diesem genutzt werden können. Die Modellierung lässt es zu, dass Kartenterminals mehreren Arbeitsplätzen lokal zugewiesen werden. Jeder an der TI teilnehmende Arbeitsplatz wird in der Regel mindestens ein lokales Kartenterminal benötigen.
    Entfernte Kartenterminals [7]
    persistent
    Diese Relation beschreibt, auf welche Kartenterminals Arbeitsplätze (remote) zugreifen dürfen. Dies ist für zentral steckende Karten vorgesehen.
    Slot eines Kartenterminals [8]
    persistent
    Die Zuordnung von Slots zu einem Kartenterminal ergibt sich automatisch aus den Eigenschaften des Kartenterminals.
    SM-B_Verwaltet eines Mandanten [9]
    persistent
    Diese Relation legt fest, welche verwalteten
    SM-Bs einem Mandanten zugeordnet sind.
    Kartenterminal-Slot, in dem eine Karte steckt [10]
    transient
    Sobald eine Karte in ein Kartenterminal gesteckt wird, ergibt sich implizit eine Relation der Karte zu dem Slot, in dem sie steckt, [6] und indirekt über [4] zum Kartenterminal.
    Mandant der Kartensitzung
    SM-B [11]
    transient
    Beim Anlegen einer Kartensitzung SM-B wird diese immer dem zugreifenden Mandanten zugeordnet.
    Arbeitsplatz der Kartensitzung eGK [12]
    transient
    Eine Kartensitzung eGK ist immer einem Arbeitsplatz zugeordnet.
    Karte einer Kartensitzung [13]
    transient
    Jeder Kartensitzung ist genau einer Karte zugeordnet.
    Gesteckte SM-B [14]
    transient
    Wird eine SM-B gesteckt und handelt es sich um eine verwaltete SM-B, ergibt sich über die iccsn die Zuordnung.
    Freischaltung einer Karte [15]
    transient
    Diese Relation erfasst die Freischaltung einer Karte durch eine andere Karte.
    Bindung der Kartensitzung_HBAx an Clientsystem [16]
    transient
    Kartensitzungen HBAx sind einem Clientsystem zugeordnet.
    AuthState pro Kartensitzung [17]
    transient
    Eine Kartensitzung kann erhöhte Sicherheitszustände (Authorization State) haben.

    Tabelle 16: TAB_KON_510 Informationsmodell Constraints

    #
    Beschreibung
    Definition mittels OCL
    (Die Constraints werden im UML ergänzenden Standard OCL definiert.)
    C1
    Eine eGK muss eine oder keine Kartensitzung haben.
    context Karte
    inv: self.type = "eGK" implies
      self.kartensitzung.size() <= 1
    C2
    Wenn zwei Kartensitzungen einer HBAx dem gleichen Clientsystem zugeordnet sind und ihre userIds gleich sind, dann müssen die beiden Kartensitzungen identisch sein.
    context Kartensitzung-HBAx
    inv: forAll(k1, k2 : Kartensitzung-HBAx |
      k1.karte = k2.karte
        and k1.clientsystem = k2.clientsystem
        and k1.userId = k2.userId
        implies
      k1 = k2)
    C3
    Wenn zwei SM-B-Kartensitzungen einer Karte dem gleichen Mandanten zugeordnet sind, dann müssen die beiden Kartensitzungen identisch sein.
    context Kartensitzung-SM-B
    inv: forAll(k1, k2 : Kartensitzung-SM-B |
      k1.karte = k2.karte
        and k1.mandant = k2.mandant implies
      k1 = k2)
    C4
    Die Seriennummer iccsn einer Karte muss eindeutig sein.
    context Karte
    inv: Karte.allInstances ->
         isUnique(iccsn)
    C5
    Die Seriennummer iccsn einer Karte muss für die vom Konnektor verwalteten
    SM-Bs eindeutig sein.
    context SM-B_Verwaltet
    inv: SM-B_Verwaltet.allInstances ->  
         isUnique(iccsn)
    C6
    Das CardHandle einer Karte muss eindeutig sein.
    context Karte
    inv: Karte.allInstances ->
         isUnique(cardHandle)
    C7
    Die Identifikationsnummer des Clientsystems muss eindeutig sein.
    context Clientsystem
    inv: Clientsystem.allInstances ->
         isUnique(clientSystemId)
    C8
    Die Identifikationsnummer des Mandanten muss eindeutig sein.
    context Mandant
    inv: Mandant.allInstances ->
         isUnique(mandantId)
    C9
    Die Identifikationsnummer des Arbeitsplatzes muss eindeutig sein.
    context Arbeitsplatz
    inv: Arbeitsplatz.allInstances ->
         isUnique(workplaceId)
    C10
    Die Identifikationsnummer des Kartenterminals muss eindeutig sein.
    context Kartenterminal
    inv: Kartenterminal.allInstances ->
         isUnique(ctId)
    C11
    Die Identifikationsnummer (slotNo) des Kartenterminal-Slots für ein gegebenes Kartenterminal muss eindeutig sein.
    context Kartenterminal
    inv: self.kT-Slot ->
         isUnique(slotNo)
    C12
    Es muss gewährleistet sein, dass nur Arbeitsplätze und Clientsysteme einander im Rahmen eines Mandanten zugeordnet werden, die diesem Mandanten selbst zugeordnet sind.
    context CS-AP
    inv: self.arbeitsplatz.mandant.includes(          
          self.mandant)
    inv: self.clientsystem.mandant.includes(          
          self.mandant)
    C13
    Es muss gewährleistet sein, dass nur Kartenterminals und Arbeitsplätze einander im Rahmen eines Mandanten zur Remote-PIN-Eingabe zugeordnet werden, die diesem Mandanten selbst zugeordnet sind.
    context Remote-PIN-KT
    inv: self.arbeitsplatz.mandant.includes(          
          self.mandant)
    inv: self.kartenterminal.mandant.includes(          
          self.mandant)
    C14
    Zur Remote-PIN-Eingabe muss ein lokales Kartenterminal ausgewählt sein.
    context Remote-PIN-KT
    inv: self.arbeitsplatz
         .localKartenterminal
         .includes(self.kartenterminal)
    inv: not self.arbeitsplatz
         .entferntKartenterminal
         .includes(self.kartenterminal)
    C15
    Zur Remote-PIN-Eingabe darf pro Mandanten und Arbeitsplatz nicht mehr als ein Kartenterminal ausgewählt werden.
    context Remote-PIN-KT
    inv: forAll(r1, r2 : Remote-PIN-KT |
      r1.arbeitsplatz = r2.arbeitsplatz
        and r1.mandant = r2.mandant implies
      r1 = r2)
    C16
    Eine Kartensitzung-HBAx muss immer eine zugehörige userId haben.
    context Kartensitzung-HBAx
    inv: self.userId <> null

    Hinweis zur Remote-PIN-Eingabe: Constraints C14 und C15 legen fest, dass auch im Fall mehrerer lokaler Kartenterminals an einem Arbeitsplatz nur eines (oder keines) dieser Kartenterminals pro Mandant für die Remote-PIN-Eingabe im Informationsmodell konfiguriert wird.

    TIP1-A_4523

    Der Konnektor MUSS seine Entscheidungen zur Zugriffsberechtigung basierend auf den aktuellen, realen statischen wie transienten Entitäten und Beziehungen des Informationsmodells treffen. Veränderungen an der statischen Definition (durch den Administrator), sowie Veränderungen an den Entitäten (Änderung der Verfügbarkeit und Zustandsänderung von Karten, Kartenterminals und Clientsystemen) MÜSSEN bei Zugriffsanfragen unmittelbare Auswirkung auf die Entscheidung des Zugriffsberechtigungsdienstes zur Folge haben.

    <=

    4.1.1.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.1.1.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.1.1.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.1.4.1 TUC_KON_000 „Prüfe Zugriffsberechtigung“

    Vor Ausführung jeder Operation an der Außenschnittstelle muss der Konnektor prüfen, ob die Operation ausgeführt werden darf (Autorisierung). Diese Prüfung auf Zugriffsberechtigung wird in TUC_KON_000 „Prüfe Zugriffsberechtigung“ gekapselt.

    TUC_KON_000 „Prüfe Zugriffsberechtigung“ hat als Aufrufparameter den Aufrufkontext der Operation (siehe Abbildung PIC_KON_101), optional das cardHandle einer Karte, optional eine Kartenterminal-ID ctId und optional die Steuerungsparameter „needCardSession“ sowie „allWorkplaces“. Über den Steuerungsparameter „needCardSession“ wird festgelegt, ob zu den CardHandles im Rahmen der Operationsausführung eine Kartensitzung benötigt wird. Über den Steuerungsparameter „allWorkplaces“. wird festgelegt, ob die Auswertung im Rahmen der Operation arbeitsplatzübergreifend für alle vom Mandanten für das angegebene Clientsystem erreichbaren Kartenterminals erfolgen soll.


    Abbildung 5: PIC_KON_101 Aufrufkontext der Operation

    TIP1-A_4524-03

    Der Konnektor MUSS den technischen Use Case TUC_KON_000 „Prüfe Zugriffsberechtigung“ umsetzen.

    Tabelle 17: TAB_KON_511-01 – TUC_KON_000 „Prüfe Zugriffsberechtigung“

    Element
    Beschreibung
    Name
    TUC_KON_000 ”Prüfe Zugriffsberechtigung”
    Beschreibung
    Es wird geprüft, ob eine Autorisierung im Rahmen der angegebenen
    Eingangsdaten erteilt wird. Die Autorisierung wurde erteilt, wenn der TUC
    erfolgreich durchlaufen wurde (kein Abbruch durch Fehlermeldung).“
    Eingangs- anforderungen
    keine
    Auslöser und Vorbedingungen
    Aufruf einer Operation des Konnektors durch das Clientsystem.
    Eingangsdaten
    • mandantId
    • clientSystemId
    • workplaceId
    • userId - optional
    • ctId - optional
      (Kartenterminalidentifikator)
    • cardHandle - optional
    • needCardSession [Boolean] – optional; default: true
        („
      needCardSession“=true; „doNotNeedCardSession“=false)
        Dieser Schalter gibt an, ob eine Kartensitzung benötigt wird
        - true, der aufrufende TUC verwendet eine Kartensitzung
        - false, der aufrufende TUC verwendet keine Kartensitzung
        Die Berechtigungsprüfung geht im Default-Fall, davon aus, dass eine    Kartensitzung benötigt wird, und prüft für diesen Fall die Berechtigung mit.
    • allWorkplaces [Boolean] – optional; default: false
      Dieser Schalter gibt an, ob eine mandantenweite Zugriffsberechtigung   gemeint ist.  
      Dieser Parameter muss dann (true) gesetzt werden, wenn die Berechtigungsprüfung nicht auf die vom angegebenen Arbeitsplatz erreichbaren Kartenterminals beschränkt ist, sondern sich auf alle vom Clientsystem (clientSystemId) und dem Mandant (mandantId) insgesamt erreichbaren Kartenterminals beziehen soll. Ist dieser Schalter gleich true, wird die Berechtigung unabhängig vom Eingangsparameter workplaceId geprüft.
    Komponenten
    Konnektor
    Ausgangsdaten
    • keine
    Nachbedingungen
    • Autorisierung erteilt
    Standardablauf
     1. Prüfe, ob die Pflichtparameter (mandantId, clientSystemId, workplaceId)
         vollständig gesetzt sind.
     2. Falls ANCL_CAUT_MANDATORY = Enabled, dann prüfe, ob die gemäß
         [TIP1-A_4516] unter Berücksichtigung von [TIP1-A_5009] und [A_21224] durchgeführte             Authentifizierung über ein dem Clientsystem zugeordnetes CS-AuthMerkmal erfolgte.
     3. Ermittle Zugriffsregel R zu den Aufrufparametern:
    3.1.     Falls der Parameter cardHandle nicht null ist, muss das Kartenobjekt
         des Informationsmodells Karte(cardHandle) ermittelt werden.
    3.2.     Zu den Parametern (ctId, cardHandle, needCardSession,
        allWorkplaces) muss mittels Tabelle „TAB_KON_513 Zugriffsregeln
        Regelzuordnung“ die Zugriffsregel R ermittelt werden.
     4. Prüfe die Bedingungen der in Schritt 3 ermittelten Regel R:
    4.1.     Zur Regel R muss die relevante Spalte in Tabelle „TAB_KON_514 
         Zugriffsregeln Definition“ ermittelt werden.
    4.2.     Jede Zeile, die in der Spalte R ein „x“ hat, muss geprüft werden:
        4.2.1     Prüfe, ob die in Spalte „Bedingung“ mittels OCL formulierte 
                Bedingung für die Eingangsdaten erfüllt ist.

    Varianten/
    Alternativen
    2.
    Bei einem Aufruf mit einem cardHandle zu den Kartentypen SMC-KT und
    UNKNOWN wird Schritt 3 in folgender Variante durchlaufen:

    Ermittle Zugriffsregel R zu den Aufrufparametern:
    3.1.    ctId wird zum cardHandle bestimmt
      Zu den Parametern (
            ctId,
            cardHandle = null,
            needCardSession = false,
            allWorkplaces = false)
    muss mittels Tabelle „TAB_KON_513 Zugriffsregeln Regelzuordnung“ die
    Zugriffsregel R ermittelt werden.
    Fehlerfälle
    Fehler im Ablauf (Standardablauf oder Varianten) führen in den folgend
    ausgewiesenen Schritten zu einem Abbruch der Verarbeitung mit den
    ausgewiesenen Fehlercodes:
    (1)       Es sind nicht alle Pflichtparameter gesetzt,
                   Fehlercode: 4021
    (2)       Clientsystem aus dem Aufrufkontext nicht authentifiziert,
                   Fehlercode: 4204
    (3.1)    Karte nicht als gesteckt identifiziert,
                   Fehlercode: 4008
    (3.2)    Zu den Parametern konnte keine Regel ermittelt werden,
                   Fehlercode: 4019
    (4.2.1) Bedingung nicht erfüllt
                   Fehlercode: wie in Spalte „ErrorCode“ der geprüften Zeile aus
                   Tabelle „TAB_KON_514-01 Zugriffsregeln Definition“
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    PIC_KON_118 Aktivitätsdiagramm zu „TUC_KON_000 Prüfe Zugriffsberechtigung“

    <=

    Eine Beschreibung aller Zugriffsregeln gibt Tabelle TAB_KON_512.

    Tabelle 18: TAB_KON_512 Zugriffsregeln Beschreibung

    Regel
    Beschreibung
    R1
    Innerhalb des Mandanten m darf das Clientsystem cs verwendet werden.
    R2
    Innerhalb des Mandanten m darf das Clientsystem cs auf das Kartenterminal kt zugreifen.
    R3
    Innerhalb des Mandanten m darf das Clientsystem cs den Arbeitsplatz ap nutzen.
    R4
    Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf das Kartenterminal kt zugreifen.
    R5
    Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf die lokal gesteckte eGK zugreifen. Eine Kartensitzung wird nicht benötigt.
    R6
    Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf die lokal gesteckte eGK zugreifen. Eine Kartensitzung wird benötigt. Wenn bereits eine Kartensitzung besteht, ist sichergestellt, dass sie vom Arbeitsplatz ap gestartet wurde.
    R7
    Innerhalb des Mandanten m darf das Clientsystem cs über den Arbeitsplatz ap auf die SM-B zugreifen. Es wird dabei sichergestellt, dass es sich um eine im Mandanten verwaltete SM-B handelt.
    R8
    Innerhalb des Mandanten m darf das Clientsystem cs auf den HBAx zugreifen. Eine Kartensitzung wird nicht benötigt.
    R9
    Innerhalb des Mandanten m darf das Clientsystem cs auf den HBAx zugreifen. Eine Kartensitzung wird benötigt. Wenn bereits Kartensitzungen zum HBAx bestehen, wird der Zugriff auf den HBAx verhindert, wenn es eine Kartensitzung zum selben Clientsystem, aber einer anderen UserId gibt, deren Sicherheitszustand erhöht ist.


    Abbildung 6: PIC_KON_118 Aktivitätsdiagramm zu „TUC_KON_000 Prüfe Zugriffsberechtigung“

    Welche Zugriffsregel für einen gegebenen Satz an Aufrufparametern anzuwenden ist, wird in Tabelle TAB_KON_513 ermittelt. Die Pflichtfelder mandantId, clientSystemId und workplaceId und das optionale Feld userId sind zwar für die Auswertung der Regeln wichtig, tragen aber nicht zur Auswahl der Regel bei und sind daher in der Tabelle nicht vorhanden. Zur Auswahl einer Regel ist relevant,

    Tabelle 19: TAB_KON_513 Zugriffsregeln Regelzuordnung

    Parameter
    R1
    R2
    R3
    R4
    R5
    R6
    R7
    R8
    R9
    ctId
    null
    not
    null
    null
    not
    null





    cardHandle
    null
    null
    null
    null
    not
    null
    not
    null
    not
    null
    not
    null
    not
    null
    Karte(cardHandle).type




    eGK
    oder
    KVK
    eGK
    oder
    KVK



    Karte(cardHandle).type






    SM-B


    Karte(cardHandle).type







    HBAx
    HBAx
    needCardSession
    false
    false
    false
    false
    false
    true
    true
    oder
    false
    false
    true
    allWorkplaces
    true
    true
    false
    false
    false
    false
    false
    false
    false

    Tabelle TAB_KON_514 definiert einzelne Bedingungen, ordnet sie den Regeln zu und definiert ErrorCodes für den Fall, dass eine Bedingung nicht erfüllt ist.

    Die Bedingungen in Tabelle TAB_KON_514 sind wie folgt gruppiert:

    Die Fehlercodes mit Beschreibung, ErrorType und Severity Tabelle TAB_KON_515.

    Tabelle 20: TAB_KON_514-01 Zugriffsregeln Definition


    Bedingung
    (siehe Hinweis 1)
    R1
    R2
    R3
    R4
    R5
    R6
    R7
    R8
    R9
    Error Code
    Entität
    (siehe Hinweis 2)
    inv : userId <> null








    x
    4003
    let m : Mandant =
    Mandant(mandantId)
    inv : m <> null
    x
    x
    x
    x
    x
    x
    x
    x
    x
    4021 an der Außenschnittstelle
    4004 im Protokoll
    (siehe Hinweis 3)

    let cs : Clientsystem
        = Clientsystem
    (clientSystemId)
    inv : cs <> null
    x
    x
    x
    x
    x
    x
    x
    x
    x
    4021 an der Außenschnittstelle
    4005 im Protokoll
    (siehe Hinweis 3)

    let ap : Arbeitsplatz
        = Arbeitsplatz
    (workplaceId)
    inv : ap <> null
     

     x
    x
    x
    x
    x
    x
    x
    4021 an der Außenschnittstelle
    4006 im Protokoll
    (siehe Hinweis 3)

    let kt : Kartenterminal
        = Kartenterminal
    (ctId)
    inv : kt <> null
     
     x

    x





    4007
    let k : Karte = Karte
    (cardHandle)
    inv :  k <> null
     
     
     
     
    x
    x
    x
    x
    x
    4008
    Mandant
    bezug
    let m : Mandant =
    Mandant(mandantId)
    let cs : Clientsystem
        = Clientsystem
    (clientSystemId)
    inv : cs.mandant.
    includes(m)
    x
    x
    x
    x
    x
    x
    x
    x
    x
    4010
    let m : Mandant =
    Mandant(mandantId)
    let ap : Arbeitsplatz
        = Arbeitsplatz
    (workplaceId)
    inv :  ap.mandant.
    includes(m)
     

    x
    x
    x
    x
    x
    x
    x
    4011
    let m : Mandant =
    Mandant(mandantId)
    let kt : Kartenterminal
      = Kartenterminal(ctId)
    inv : kt.mandant.
    includes(m)
     
     x

    x





    4012
    let m : Mandant =
    Mandant(mandantId)
    let k : Karte =
    Karte(cardHandle)
    inv : k.kT-Slot.
    kartenterminal.mandant
           .includes(m)




    x
    x
    x
    x
    x
    4012
    Relation
    let k : Karte =
    Karte(cardHandle)
    inv : k.SM-B_Verwaltet
    <> null
     
     
     
     
     
     
    x
     
     
    4009
    let m : Mandant =
    Mandant(mandantId)
    let k : Karte =
    Karte(cardHandle)
    inv : k.SM-B_Verwaltet
    .mandant
          -> includes(m)
     
     
     
     
     
     
    x
     
     
    4013
    let m : Mandant =
    Mandant(mandantId)
    let cs : Clientsystem
        = Clientsystem
    (clientSystemId)
    let ap : Arbeitsplatz
        = Arbeitsplatz
    (workplaceId)
    inv : CS_AP.allInstances
    -> exists(c : CS_AP |
              c.mandant = m
              and
    c.arbeitsplatz = ap
              and
    c.clientsystem = cs)
     

    x
    x
    x
    x
    x
    x
    x
    4014
    let ap : Arbeitsplatz
        = Arbeitsplatz
    (workplaceId)
    let kt : Kartenterminal
        = Kartenterminal
    (ctId)
    inv :
      ap.lokalKartenterminal
    .includes(kt) or   
      ap.entferntKarten
    terminal
    .includes(kt)
     
     

    x
     
     



    4015
    let ap : Arbeitsplatz
        = Arbeitsplatz
    (workplaceId)
    let kt : Kartenterminal
    = Karte(cardHandle).kT-Slot.kartenterminal
    inv :
      ap.lokalKartenterminal
    .includes(kt) or   
      ap.entferntKarten
    terminal
    .includes(kt)






    x
    x
    x
    4015
    let m : Mandant = Mandant
    (mandantId)
    let kt : Kartenterminal
        = Kartenterminal(ctId)
    let cs : Clientsystem = Clientsystem
    (clientSystemId)
    inv : CS_AP.allInstances
    -> exists(c : CS_AP |
    c.arbeitsplatz
    .lokalKartenterminal
       .includes(kt) or
    c.arbeitsplatz
    .entferntKartenterminal
       .includes(kt)
    and c.mandant = m
    and c.arbeitsplatz.mandant
    .includes(m)
    and c.clientsystem = cs)

    x







    4020
    let ap : Arbeitsplatz
        = Arbeitsplatz
    (workplaceId)
    let kt : Kartenterminal
    = Karte(cardHandle).kT-Slot.kartenterminal
    inv : ap.lokalKartenterminal
    .includes(kt)
     
     
     
     
    x
    x
     
     
     
    4016
    Karten
    sitzungen
    let ap : Arbeitsplatz
        = Arbeitsplatz
    (workplaceId)
    let k : Karte =
    Karte(cardHandle)
    inv : k.kartensitzung
          -> not exists(ks : Kartensitzung |
               ks.arbeitsplatz
    <> ap)
     
     
     
     

    x
     
     
     
    4017
    let k : Karte = Karte
    (cardHandle)
    let cs : Clientsystem
        = Clientsystem
    (clientSystemId)
    inv : k.kartensitzung  
      ->  not exists
    (ks : Kartensitzung |  
                ks
    .clientsystem = cs and
                ks
    .userId <> userId and
                ks
    .authState.size() > 0
          )
     
     
     
     
     
     
     

    x
    4018

    Erläuterungen zu TAB_KON_514-01:

    Hinweis 1:
    Jede Bedingung ist als Constraint mittels OCL definiert, ist einzeln prüfbar und hat als Eingangsparameter mandantId, clientSystemId, workplaceId, ctId, cardHandle und userId.

    Hinweis 2:
    Zur Bezeichnung einer Objektinstanz, die im Informationsmodell vorhanden ist, wird die Notation <<Entitätsbezeichner>>(<<Komma separierte Liste der Identitätsschlüssel>> verwendet.

    Hinweis 3:
    Bei manchen Bedingungen gibt es unterschiedliche Fehlermeldungen für die Außenschnittstelle und für die interne Protokollierung. Dann wird folgende Notation in Spalte "Error Code" verwendet:

    "<<Fehlercode>> an der Außenschnittstelle" für den Fehlercode, der über die Außenschnittstelle zurückgegeben werden muss

    "<<Fehlercode>> im Protokoll" für den Fehlercode, der für die interne Protokollierung verwendet werden muss. 

    Tabelle 21: TAB_KON_515 Fehlercodes TUC_KON_000 „Prüfe Zugriffsberechtigung“

    Fehlercode ErrorType Severity Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4003
    Technical
    Error
    Keine User-ID angegeben, die zur Identifikation der Kartensitzung_HBAx benötigt wird.
    4004
    Technical
    Error
    Ungültige Mandanten-ID
    4005
    Technical
    Error
    Ungültige Clientsystem-ID
    4006
    Technical
    Error
    Ungültige Arbeitsplatz-ID
    4007
    Technical
    Error
    Ungültige Kartenterminal-ID
    4008
    Technical
    Error
    Karte nicht als gesteckt identifiziert
    4009
    Security
    Error
    SM-B ist dem Konnektor nicht als SM-B_Verwaltet bekannt
    4010
    Security
    Error
    Clientsystem ist dem Mandanten nicht zugeordnet
    4011
    Security
    Error
    Arbeitsplatz ist dem Mandanten nicht zugeordnet
    4012
    Security
    Error
    Kartenterminal ist dem Mandanten nicht zugeordnet
    4013
    Security
    Error
    SM-B_Verwaltet ist dem Mandanten nicht zugeordnet
    4014
    Security
    Error
    Für den Mandanten ist der Arbeitsplatz nicht dem Clientsystem zugeordnet
    4015
    Security
    Error
    Kartenterminal ist weder lokal noch entfernt vom Arbeitsplatz aus zugreifbar
    4016
    Security
    Error
    Kartenterminal ist nicht lokal vom Arbeitsplatz aus zugreifbar
    4017
    Security
    Error
    Die eGK hat bereits eine Kartensitzung, die einem anderen Arbeitsplatz zugeordnet ist.
    4018
    Security
    Error
    Der HBAx hat mindestens eine Kartensitzung zu einer anderen UserId, deren Sicherheitszustand erhöht ist.(Sicherheitszustand wird bei PIN-Eingabe erhöht.)
    4019
    Technical
    Error
    Zu den Parametern konnte keine Regel ermittelt werden.
    4020
    Security
    Error
    Kartenterminal ist weder lokal noch entfernt über irgendeinen dem Clientsystem zugeordneten Arbeitsplatz aus zugreifbar
    4021
    Technical
    Error
    Es sind nicht alle Pflichtparameter mandantId, clientSystemId, workplaceId gefüllt.
    4204
    Security
    Error
    Clientsystem aus dem Aufrufkontext konnte nicht authentifiziert werden.

    Hinweis zu Fehler 4018: Sicherheitszustand wird bei PIN-Eingabe erhöht.

    4.1.1.5 Operationen an der Außenschnittstelle

    Keine

    4.1.1.6 Betriebsaspekte

    TIP1-A_4525

    Der Konnektor MUSS mit Abschluss der Bootup-Phase den Ist-Zustand transienter Entitäten und Beziehungen des Informationsmodells erfasst haben.

    <=

    TIP1-A_4526

    Für die Administration MUSS der Konnektor eine Administrationsoberfläche zur Pflege des Informationsmodells zur Verfügung stellen. Die Oberfläche muss es ermöglichen, sämtliche persistente Entitäten und Beziehungen des durch Abbildung PIC_Kon_100 Informationsmodell des Konnektors und Tabelle „TAB_KON_510 Informationsmodell Constraints“ definierten Informationsmodells initial anzulegen, zu ändern und zu löschen.

    <=

    Im Anhang I „Umsetzungshinweise“ werden Empfehlungen zur Umsetzung der Administration des Informationsmodells gegeben.

    4.1.2 Dokumentvalidierungsdienst

    Der Dokumentvalidierungsdienst ist ein Dienst, der nur intern genutzt wird, d. h., dass dessen definierte Verhaltensweisen nur in anderen TUCs des Konnektors nachgenutzt werden. Er bietet Schnittstellen zum Validieren von Dokumenten an. Dabei werden diejenigen spezifischen Dokumentformate unterstützt, die an den Außenschnittstellen anderer Dienste wie Signatur- und Verschlüsselungsdienst auftreten können (Alle_DocFormate gemäß Kapitel 3).

    Die jeweils gültigen XML-Schemas der Fachmodule werden den Herstellern von der gematik bereitgestellt.

    4.1.2.1 Funktionsmerkmalweite Aspekte

    A_18780

    Der Konnektor DARF Dokumente im PDF/A-3 Format NICHT unterstützen.
    <=

    4.1.2.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.1.2.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine

    4.1.2.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.2.4.1 TUC_KON_080 „Dokument validieren”

    TIP1-A_4527-04

    Der Konnektor MUSS den technischen Use Case TUC_KON_080 „Dokument validieren” umsetzen.

    Tabelle 22: TAB_KON_143 – TUC_KON_080 „Dokument validieren“

    Element
    Beschreibung
    Name
    TUC_KON_080 „Dokument validieren“
    Beschreibung
    Dieser TUC prüft das Format eines Dokuments und führt dokumententyp-spezifische Validierungen durch. Unterstützt werden Alle_DocFormate(außer „Binär“).
    Auslöser
    • Aufruf durch Fachmodul
    • Aufruf durch Basisdienst
    Vorbedingungen
    keine
    Eingangsdaten
    •  documentToBeValidated
      (Zu validierendes Dokument.)

    •  documentFormat
      (mögliche Werte siehe Definition
      Alle_DocFormate;
      Formatangabe für das Dokument)
    Optional für XML-Dokumente:
    •  xmlSchemas – optional/nur für XML-Dokumente
      (XML-Schema und ggf. weitere vom Hauptschema benutzte Schemata)

    •  signaturePolicyIdentifier – optional/nur für  XML-Formate gemäß einer referenzierten Signaturrichtlinie
      (URI identifiziert die Signaturrichtlinie)

    Komponenten
    Konnektor
    Ausgangsdaten
    •  documentValidationProtocol
      (Prüfprotokoll)
      Die Ausprägung dieses Konnektor-internen Parameters erfolgt herstellerspezifisch.

    Nachbedingungen
    Keine
    Standardablauf
    Validierung der Dokumente auf Typkonformität
    Der Konnektor führt je nach Format des Dokuments (documentFormat) eine der folgenden Prüfungen durch:

    A) XML-Dokumentvalidierung
    Im Fall eines XML-Dokuments prüft der Konnektor:
    • Prüfe die XML-Wohlgeformtheit des Dokumentes (documentToBeValidated)
    • Wenn signaturePolicyIdentifier vorhanden ist, dann ermittle das xmlSchema aus der referenzierten Signaturrichtlinie und prüfe die Validität von documentToBeValidated in Bezug auf das hinterlegte XML-Schema. Der Eingangsparameter xmlSchemas wird ignoriert.
    • Wenn signaturePolicyIdentifier nicht vorhanden ist und xmlSchemas übergeben wurden, dann prüfe die Wohlgeformtheit von xmlSchemas und die Validität von documentToBeValidated in Bezug auf xmlSchemas.
    • Wenn nicht durch Prüfung gegen XML-Schema bereits erfolgt, dann prüfe die Eindeutigkeit der ID-Attributwerte im XML-Dokument.  
    B) PDF/A-Dokumentvalidierung
    PDF/A-Dokumente werden geprüft, ob sie sich als PDF/A Dokumente in ihren PDF/A-Metadaten ausweisen. Es werden alle PDF/A-1 und PDF/A-2 konformen Dokumente unterstützt, einschließlich PDF/A-1A, PDF/A-1B, PDF/A-2A, PDF/A-2B, PDF/A-2U.

    Beispiele:
    <pdfaid:part xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">1</pdfaid:part>
    <rdf:Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/" pdfaid:part="1" pdfaid:conformance="B"/>

    C) TIFF-Dokumentvalidierung

    Der Konnektor prüft, ob das Dokument an Hand seiner ersten 8 Byte als TIFF-Dokument [TIFF6] zu identifizieren ist.
    D) MIME-Dokumentvalidierung
    Die Struktur von MIME-Dokumenten wird entsprechend [MIME] validiert.
    E) Text-Dokumentvalidierung
    Der Konnektor prüft die Konformität zum im Dokumentenformat vorgegebenen Character-Encoding.
    Für Binärdokumente findet keine Validierung statt.
    Hinweis: Byte-order-marks (BOM) sind im Rahmen von UTF-8 kodierten Dokumenten gemäß UTF8 Standard ([RFC3629], Kapitel 6) erlaubt, aber nicht notwendigerweise im Dokument vorhanden.

    Validierung der Dokumentformate
    Der Konnektor prüft für das Dokument, ob die Vorgaben zu Dokumenten aus Kapitel 3.1.1 "Dokumentformate" eingehalten sind.
    Varianten/
    Alternativen

    keine
    Fehlerfälle
    Standardablauf:
    Bei der Dokumentenvalidierung protokolliert der TUC alle aufgetretenen Fehler im Rückgabewert documentValidationProtocol.

    Validierung der Dokumente auf Typkonformität
    (A) Fehlerfälle bei XML-Dokumentvalidierung
    Wenn keine Schemata übergeben wurden (xmlSchemas oder signaturePolicyIdentifier nicht vorhanden): Fehlercode 4193
    Wenn eines der übergebenen Schemata selbst nicht wohlgeformt oder invalide ist, wird Fehlercode 4026 gemeldet.
    Wenn das XML-Dokument nicht wohlgeformt ist, wird Fehlercode 4022 gemeldet.
    Das XML-Dokument ist nicht valide in Bezug auf das zur Validierung benutzte Schema (xmlSchemas bzw. signaturePolicyIdentifier): Fehlercode 4023.
    (B) Fehlerfälle bei PDF/A-Dokumentvalidierung
    Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = PDF/A
    (C) Fehlerfälle bei TIFF-Dokumentvalidierung
    Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = TIFF
    (D) Fehlerfälle bei MIME-Dokumentvalidierung
    Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = MIME
    (E) Fehlerfälle bei Text-Dokumentvalidierung
    Bei fehlgeschlagener Validierung: Fehlercode 4024, Dokumentformat = Text

    Validierung der Dokumentformate
    Bei Verletzung einer Vorgabe aus Kapitel 3.1.1 bricht der Konnektor die Verarbeitung mit einem entsprechenden Fehlercode ab.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 23: TAB_KON_144 Fehlercodes TUC_KON_080 „Dokument validieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases und Fehlercodes aus Kapitel 3.1.1  können folgende weitere Fehlercodes auftreten:
    4022
    Security
    Error
    XML-Dokument nicht wohlgeformt
    4023
    Security
    Error
    XML-Dokument nicht valide in Bezug auf XML-Schema
    4024
    Security
    Error
    Formatvalidierung fehlgeschlagen (<Dokumentformat>)
    Der Parameter Dokumentformat kann die Werte XML, PDF/A, TIFF, MIME und Text annehmen.
    4026
    Security
    Error
    XML-Schema nicht valide
    4193
    Security
    Warning
    kein XML-Schema für XML-Dokument vorhanden

    <=

    4.1.2.5 Operationen an der Außenschnittstelle

    Keine

    4.1.2.6 Betriebsaspekte

    Keine

    4.1.3 Dienstverzeichnisdienst

    Der Dienstverzeichnisdienst liefert dem aufrufenden Clientsystem sowohl Informationen über die Version und Produktkenndaten des Konnektors, als auch die SOAP-Endpunkte, über die das Clientsystem die einzelnen Dienstoperationen erreichen kann.

    4.1.3.1 Funktionsmerkmalweite Aspekte

    Die Endpunkte der Basisdienste werden in WSDL spezifiziert. Diese Endpunkte und weitere konnektormodellspezifische Informationen werden dem Clientsystem in Form eines Dienstverzeichnisdienstes gesammelt angeboten.

    Der prinzipielle Ablauf sieht dabei folgendermaßen aus:

    Das Clientsystem ruft beim Initialisieren des Systems mit HTTP-GET die vordefinierte URL:     https://<ANLW_LAN_IP_ADDRESS oder     MGM_KONN_HOSTNAME>/connector.sds oderhttp://<ANLW_LAN_IP_ADDRESS oder MGM_KONN_HOSTNAME>/connector.sds des Konnektors auf.

    Der Konnektor stellt die Liste der Dienste, der Versionen und die Endpunkte der Dienste in einem XML-Dokument zusammen. Jeder über SOAP erreichbare Basisdienst des Konnektors wird in dieser Liste geführt. Ferner können Fachmodule ihre eigenen Endpunkte über TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“ einbringen. Die so erstellte Liste der Dienste wird als Antwort an das Clientsystem übergeben.

    Das Clientsystem prüft, ob die gewünschten Dienste und Versionen unterstützt werden und merkt sich die Endpunkte der Dienste für die späteren Aufrufe. Danach kann das Clientsystem diese Dienstendpunkte nach Bedarf aufrufen.

    TIP1-A_4528

    Der Konnektor MUSS den Dienstverzeichnisdienst anbieten. Dieser Dienst veröffentlicht auf:     https://$ANLW_LAN_IP_ADDRESS oder $MGM_KONN_HOSTNAME>/connector.sds oder     http://$ANLW_LAN_IP_ADDRESS oder $MGM_KONN_HOSTNAME>/connector.sds.

    Die Datei MUSS über https erreichbar sein.

    Wenn (ANCL_DVD_OPEN = Enabled) oder (ANCL_TLS_MANDATORY = Disabled) MUSS die Datei auch über http erreichbar sein.

    <=

    TIP1-A_4529-02

    Das XML-Dokument, welches als „connector.sds“ dem Aufrufer zurückgeliefert wird, MUSS gemäß dem Schema „conn/ServiceDirectory.xsd“ formatiert sein. conn/ServiceDirectory.xsd referenziert die Schemata „tel/version/ProductInformation.xsd“ (siehe [gemSpec_OM]) und „conn/ServiceInformation.xsd“.
    TAB_KON_516, TAB_KON_517 und TAB_KON_518 beschreiben die Elemente der zu verwendenden Schemastruktur.

    Tabelle 24: TAB_KON_516 Basisanwendung Dienstverzeichnisdienst

    Name
    ConnectorServiceDirectory
    Version
    3.1.0 (XSD-Version)
    Namensraum
    Siehe GitHub
    Namensraum-Kürzel
    CONN
    Operationen
    Lesen der vom Konnektor unterstützten Dienste
    WSDL
    Keine
    Schema
    ServiceDirectory.xsd

    Tabelle 25: TAB_KON_517 Schemabeschreibung Produktinformation (ProductInformation.xsd)




    Element
    Bedeutung
    ProductInformation/InformationDate
    Datum der Informationsabfrage über das Produkt
    ProductInformation/ProductTypeInformation/
    ProductType
    Produkttyp (Konnektor)
    ProductInformation/ProductTypeInformation/
    ProductTypeVersion
    Produkttypversion des Konnektormodells
    ProductInformation/ProductIdentification/
    ProductVendorID
    ID des Konnektorherstellers
    ProductInformation/ProductIdentification/
    ProductCode
    Produktkürzel
    ProductInformation/ProductIdentification/
    ProductVersion/Local/HWVersion
    Hardwareversion des Konnektormodells
    ProductInformation/ProductIdentification/
    ProductVersion/Local/FWVersion
    Firmwareversion des Konnektormodells
    ProductInformation/ProductMiscellaneous/
    ProductVendorName
    Name des Konnektorherstellers
    ProductInformation/ProductMiscellaneous/
    ProductName
    Produktname

    Tabelle 26: TAB_KON_518 Schemabeschreibung Serviceinformation (Serviceinformation.xsd)




    Element
    Bedeutung
    ServiceInformation/Service
    Element beschreibt einen Dienst oder ein Fachmodul
    ServiceInformation/Service/@Name
    Name des Dienstes. Dieser Wert korrespondiert mit dem Feld „Name“ aus der jeweiligen Basisanwendung/Dienstbeschreibung (englischer Dienstname in Tabelle TAB_KON_798).
    ServiceInformation/Service/Abstract
    eine kurze textuelle Beschreibung des Dienstes/Fachmoduls
    ServiceInformation/Service/Versions
    die Liste der unterstützten Versionen
    ServiceInformation/Service/Versions/Version
    Beschreibung der Dienstversion/Fachmodulversion
    ServiceInformation/ Service/Versions/Version/@TargetNamespace
    der Namensraum der Dienst-/Fachmodulversion
    ServiceInformation/Service/Versions/Version/@Version
    Vollständige Versionsnummer (Konnektordienstversion) des Dienstes/Fachmoduls. Dieser Wert entspricht dem Wert „WSDL-Version“ des jeweiligen Dienstes in Tabelle TAB_KON_798.
    ServiceInformation/Service/Versions/Version/Abstract
    Eine kurze textuelle Beschreibung dieser Version des Dienstes/Fachmoduls
    ServiceInformation/ Service/Versions/Version/EndpointTLS/@Location
    Absoluter URL des über TLS erreichbaren Dienstes.
    ServiceInformation/ Service/Versions/Version/Endpoint/@Location
    Absoluter URL des erreichbaren Dienstes (ohne TLS).
    ServiceInformation/ Service/Versions/Version/WSDL/@Location
    (optional) Absoluter URL der WSDL-Beschreibung


    <=

    TIP1-A_4530

    Die URLs der Dienste KÖNNEN herstellerspezifisch aufgebaut werden.

    <=

    4.1.3.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.1.3.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine

    4.1.3.4 Interne TUCs, auch durch Fachmodule nutzbar

    Da der Konnektor als Black-Box mit inkludierten Fachmodulen ohne erkennbare Innenschnittstellen spezifiziert wird, stellt der folgende TUC lediglich einen Mechanismus zur editoriellen Kopplung der Fachmodulspezifikationen mit der Konnektorspezifikation dar:

    4.1.3.4.1 TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“

    TIP1-A_4531

    Der Dienstverzeichnisdienst des Konnektors MUSS es den Fachmodulen ermöglichen, die zum jeweiligen Fachmodul gehörenden Endpunkte während der Bootup-Phase des Konnektors in den Dienstverzeichnisdienst einzubringen.

    Tabelle 27: TAB_KON_519 - TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“

    Element
    Beschreibung
    Name
    TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“
    Beschreibung
    Fachmodule MÜSSEN ihre Endpunktinformationen während der Bootup-Phase in den Dienstverzeichnisdienst einbringen können.
    Auslöser und Vorbedingungen
    Keine
    Eingangsdaten
    • serviceInformation
      (Ein XML-Dokument mit dem Wurzelelement „ServiceInformation“ gemäß dem Schema „Serviceinformation.xsd“. Eine Beschreibung des Schemas befindet sich in TAB_KON_518.)

    Komponenten
    Konnektor, Fachmodule
    Ausgangsdaten
    • Keine
    Standardablauf
    Die übergebenen Serviceinformationen des Fachmoduls werden in die Gesamtstruktur „connector.sds“ aufgenommen.
    Falls beim Speichern der eingebrachten Endpunktinformationen ein Fehler auftritt, wird Fehler 4027 ausgelöst.
    Varianten/Alternativen
    Keine
    Fehlerfälle
    4027: Die Endpunktinformationen konnten nicht übernommen werden.
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 28: TAB_KON_520 Fehlercodes TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4027
    Technical
    Error
    Die Endpunktinformationen konnten nicht übernommen werden.

    <=

    4.1.3.5 Operationen an der Außenschnittstelle

    TIP1-A_4532

    Der Dienstverzeichnisdienst des Konnektors MUSS die in Tabelle TAB_KON_521 Schnittstelle der Basisanwendung Dienstverzeichnisdienst beschriebene Schnittstelle anbieten.

    Tabelle 29: TAB_KON_521 Schnittstelle der Basisanwendung Dienstverzeichnisdienst

    Dienstname

    ConnectorServiceDirectory

    Beschreibung

    Der Aufruf liefert Angaben über den Hersteller, über das Konnektormodell und die Liste der Dienste, Konnektordienstversionen (KDV) und Endpunkte der Dienste.

    Aufruf

    GET /connector.sds HTTP/1.1
    Host: ANLW_LAN_IP_ADDRESS oder MGM_KONN_HOSTNAME

    Rückgabe

    Das Antwortdokument ist in der Schemadatei ServiceDirectory.xsd beschrieben.

    ConnectorServices




    Name

    Beschreibung

    ProductInformation

    Kurzbeschreibung des Konnektormodells

    ServiceInformation

    Beschreibung der Dienste

    ProductInformation:
    Das Schema wird in TAB_KON_517 beschrieben. Die Felder sind gemäß [gemSpec_OM] zu befüllen und gemäß dem Schema ProductInformation.xsd zu formatieren.

    TLS-Mandatory: Boolean Wert der festlegt, ob die Verwendung eines TLS-Kanals für Dienstaufrufe verpflichtend ist.
    Definierende Variable ist: ANCL_TLS_MANDATORY
    ClientAutMandatory: Boolean Wert der festlegt, ob Client Authentifizierung verpflichtend ist.
    Definierende Variable ist: ANCL_CAUT_MANDATORY.

    ServiceInformation:
    Das Schema wird in TAB_KON_518 beschrieben. Die Felder sind gemäß dem Schema ServiceInformation.xsd zu formatieren.
    Falls (ANCL_CAUT_MANDATORY = Enabled) oder (ANCL_TLS_MANDATORY = Enabled), MUSS die Rückgabedatei ausschließlich https-Endpunkte enthalten.

    Fehlercodes

    Die Standard HTTP1.1 Fehlercodes [RFC2616]

    Vorbedingungen

    Keine

    Nachbedingungen

    Keine

    Hinweise

    Keine


    ​​

    <=

    4.1.3.6 Betriebsaspekte

    TIP1-A_4533

    Mit Abschluss der Bootup-Phase MUSS der Dienstverzeichnisdienst an der Außenschnittstelle die vollständige Liste aller Services bereitstellen, die der Anwendungskonnektor den Clientsystemen anbietet, inklusive der Services der Fachmodule.

    <=

    4.1.4 Kartenterminaldienst

    Die Aufgabe des Kartenterminaldienstes ist das Management aller vom Konnektor adressierbaren Kartenterminals. Dies umfasst alle administrativen Prozesse (insbesondere das Pairing, vgl. [gemSpec_KT#2.5.2]). Ferner kapselt der Kartenterminaldienst die Zugriffe auf Kartenterminals durch Basisdienste und Fachmodule.

    Für die TLS-Verbindungen zu den Kartenterminals muss der Konnektor die Vorgaben aus [gemSpec_Krypt#3.3.2] und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen.

    Innerhalb des Kartenterminaldienstes werden folgende Präfixe für Bezeichner verwendet:

    Der Kartenterminaldienst verwaltet hinsichtlich der Kartenterminals mindestens die in der informativen Tabelle TAB_KON_522 Parameterübersicht des Kartenterminaldienstes ausgewiesenen Parameter, weitere herstellerspezifische Parameter sind möglich. Die normative Festlegung wann welche Parameter mit welchen Werten belegt werden, erfolgt in den folgenden Abschnitten und Unterkapiteln.

    Dabei beschrieben CTM_xyz-Bezeichner Parameter, die den Dienst als Ganzes betreffen. Zu jedem Kartenterminal selbst werden dessen Parameter in einem CT-Object gekapselt. Die folgende Tabelle zeigt die Attribute der jeweiligen CT-Objekte über Punktschreibweise.

    Tabelle 30: TAB_KON_522 Parameterübersicht des Kartenterminaldienstes

    ReferenzID
    Belegung
    Zustandswerte
    CTM_CT_LIST
    Liste von
    CT-Objekten
    Eine Liste von Repräsentanzen (CT-Objects) der dem Konnektor bekannten Kartenterminals.
    Pro CTM_CT_LIST
    Eintrag:


    Gerätekenndaten


    CT.CTID
    Identifier
    Eindeutige, statische Identifikation des Kartenterminals
    CT.IS_PHYSICAL
    Ja/Nein
    Kennzeichnung, ob es sich um ein physisches oder logisches Kartenterminal handelt, zur Unterscheidung von eHealth-Kartenterminals und HSM-Bs.
    Da dieser Unterschied gemäß der aktuellen HSM-B-Lösung für den Konnektor transparent ist, wird der Parameter in dieser Spezifikation immer auf „Ja“ gesetzt.
    Der Parameterwert „Nein“ ist für zukünftige Nutzung vorgesehen.
    CT.MAC_ADRESS
    MAC-Adresse
    Die MAC-Adresse des Kartenterminals
    CT.HOSTNAME
    String
    SICCT-Terminalname des Kartenterminals, auch als FriendlyName bezeichnet
    CT.IP_ADRESS
    IP-Adresse
    Die IP-Adresse des Kartenterminals
    CT.TCP_PORT
    Portnummer
    Der TCP-Port des SICCT-Kommandointerpreters des Kartenterminals
    CT.SLOTCOUNT
    Nummer
    Anzahl der Slots des Kartenterminals
    CT.SLOTS_USED
    Liste
    Liste der aktuell mit Karten belegten Slots
    CT.PRODUCT
    INFORMATION
    Inhalt
    ProductIn
    formation.xsd
    Die Herstellerinformationen zum Kartenterminal gemäß [gemSpec_OM]
    CT.EHEALTH_
    INTERFACE_VERSION
    Version
    Die EHEALTH-Interface-Version des Kartenterminals, die mittels GET STATUS aus dem Element VER des Discretionary Data Objects ermittelt wurde.
    CT.VALID_VERSION
    Boolean
    True, wenn die Version des Kartenterminals (CT.EHEALTH_INTERFACE_VERSION) durch den Konnektor unterstützt wird, d.h. zu den in CTM_SUPPORTED_KT_VERSIONS passt
    Default-Wert = false
    CT.DISPLAY_CAPABILITIES
    Datenstruktur
    Displayeigenschaften wie in der Struktur Display Capabilities Data Object in [SICCT#5.5.10.17] beschrieben
    Pairingdaten


    CT.SMKT_AUT
    X.509-Cert
    C.SMKT.AUT-Zertifikat des Kartenterminals, gespeichert im Rahmen des Pairings
    CT.SHARED_SECRET

    ShS.KT.AUT, gespeichert im Rahmen des Pairings
    Verbindungsdaten


    CT.CORRELATION
    bekannt
    zugewiesen
    gepairt
    aktiv
    aktualisierend
    Der Korrelationsstatus zum Konnektor:
    • bekannt (über Service Announcement/Service Discovery gelernte Kartenterminals),
    • zugewiesen (durch den Administrator aus dem Bereich der bekannten Kartenterminals oder manuell konfigurierte Kartenterminals),
    • gepairt (Pairing erfolgreich aber noch nicht zum Verbindungsaufbau freigegeben)
    • aktiv (durch Administrator zum Verbindungsaufbau freigegeben),
    • aktualisierend (ein laufender Updatevorgang, ausgelöst durch den Konnektor; Der Zustand tritt ein, wenn der Kartenterminaldienst das Event „KSR/UPDATE/START" fängt und endet mit dem Event „KSR/UPDATE/END")
    CT.CONNECTED
    Ja/Nein
    Der Verfügbarkeitsstatus des Kartenterminals (Ja = nach Aufbau der TLS-Verbindung und erfolgter zweiter Authentifizierung)
    CT.ACTIVEROLE
    User/Admin
    Benutzerrolle, die für die aktuelle Session verwendet wird
    KT-Admin-Credentials


    CT.ADMIN_USERNAME
    String
    Username des Administrators am KT
    CT.ADMIN_PASSWORD
    String
    Password des Administrators am KT

    Zum besseren Verständnis sind die Zustände, die ein Kartenterminal einnehmen kann, im nachfolgenden Zustandsdiagramm PIC_KON_071 dargestellt.

    Abbildung 7: PIC_KON_071 Korrelationszustände eines eHealth-KT

    4.1.4.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4534

    Der Kartenterminaldienst MUSS Kartenterminals nach der eHealth-Kartenterminal Spezifikation [gemSpec_KT] unterstützen.

    <=

    Zur Unterstützung von HSM-Bs benötigt der Konnektor virtuelle Kartenterminals (CT.IS_PHYSICAL=Nein), in denen virtuelle SMC-Bs „stecken“ können (siehe Kapitel 4.1.4). Diese Kartenterminals werden innerhalb des Zugriffsberechtigungsdienstes sowie des Systeminformationsdienstes wie normale Kartenterminals berücksichtigt. Weitere Details zu den logischen Kartenterminals finden sich im Kapitel Betriebsaspekte.

    TIP1-A_4535

    Der Kartenterminaldienst MUSS logische Kartenterminals mit logischen Slots unterstützen. Zu jedem verwalteten HSM (siehe Kartendienst) MUSS der Konnektor ein oder mehrere logische Kartenterminal mit folgenden Bedingungen vorhalten:

    <=

    TIP1-A_4536

    Der Kartenterminaldienst MUSS jede mit einem Kartenterminal etablierte Verbindung durch Nutzung des in [SICCT#6.1.4.5] definierten Keep-Alive Mechanismus halten. Der Konnektor MUSS für das Heartbeat-Interval gemäß [SICCT#6.1.4.5] den Wert CTM_KEEP_ALIVE_INTERVAL verwenden und beim Ausbleiben von Terminal-Antworten eines Kartenterminals nach der Anzahl von  CTM_KEEP_ALIVE_TRY_COUNT Versuchen die Netzwerkverbindung zu diesem Kartenterminal beenden.

    <=

    TIP1-A_6725

    Der Konnektor MUSS steuern, dass Textanzeigen am Kartenterminal nur so lange angezeigt werden, wie sie im jeweiligen Anwendungskontext benötigt werden.

    <=

    Ziel der Textanzeigen am Kartenterminal ist die Kommunikation mit dem Benutzer zur Unterstützung der Anwendungsfälle. Die Anzeige am Kartenterminal muss daher einen engen zeitlichen Bezug zum jeweiligen Anwendungskontext haben.

    Nachrichten, deren Anwendungskontext mit einem Event beendet werden, wie etwa die Aufforderung zum Stecken der Karte im Kontext von TUC_KON_056, deren inhaltliche Berechtigung mit dem Stecken der Karte erlischt, (ebenso zum Ziehen der Karte im Rahmen von TUC_KON_057) müssen sofort gelöscht werden, wenn das Event eintritt.  

    Nachrichten, deren Lebensdauer nicht durch ein natürliches Event beendet wird, müssen eine vordefinierte Lebensdauer erhalten, die per Konfiguration an die Bedürfnisse der Leistungserbringer anpassbar sein sollte. Das gilt für Ergebnisanzeigen oder Anzeigen von Fehlern.

    TIP1-A_4537

    Tritt ein Timeout ein oder wird eine Netzwerkverbindung zu einem Kartenterminal (oder zu einem HSM, welches einem logischen Kartenterminal zugeordnet ist) beendet oder zurückgesetzt und ist CT.CONNECTED = Ja, so MUSS der Konnektor:

    <=

    TIP1-A_4538

    Sind in CTM_CT_LIST Kartenterminals mit CT.CONNECTED=Nein und CT.VALID_VERSION = True und CT.CORRELATION = „aktiv“ und ist CTM_SERVICE_DISCOVERY_CYCLE>0, MUSS der Konnektor im Zeitabstand CTM_SERVICE_DISCOVERY_CYCLE-Minuten entweder eine Service Discovery-Nachricht an alle KTs als Broadcast oder an jedes einzelne dieser unverbundenen KTs als Unicast senden.
    <=

    TIP1-A_4538-02

    Sind in CTM_CT_LIST Kartenterminals mit CT.CONNECTED=Nein und CT.VALID_VERSION = True und CT.CORRELATION = „aktiv“ und ist CTM_SERVICE_DISCOVERY_CYCLE>0, MUSS der Konnektor im Zeitabstand CTM_SERVICE_DISCOVERY_CYCLE-Minuten an jedes einzelne dieser unverbundenen KTs eine Service-Discovery-Nachricht als Unicast senden.
    <=

    TIP1-A_6478

    Der Kartenterminaldienst DARF SICCT-bzw. EHEALTH-Kommandos NICHT an ein Kartenterminal senden, wenn für dieses Kartenterminal CT.CONNECTED=Nein gesetzt ist. Ausgenommen hiervon sind die in TAB_KON_785 gelisteten EHEALTH- bzw. SICCT-Kommandos.

    <=

    Tabelle 31: TAB_KON_785 Erlaubte SICCT-Kommandos bei CT.CONNECTED=Nein

    SICCT-Kommando
    SICCT CT INIT CT SESSION
    SICCT CT CLOSE SESSION
    SICCT GET STATUS
    SICCT SET STATUS
    SICCT CT DOWNLOAD INIT
    SICCT CT DOWNLOAD DATA
    SICCT CT DOWNLOAD FINISH
    EHEALTH TERMINAL AUTHENTICATE

    TIP1-A_4539

    Das Ziehen einer Karte während einer Kartenaktion DARF NICHT dazu führen, dass das verwaltete Kartenterminal im Anschluss durch den Konnektor nicht weiter genutzt werden kann. Die entsprechende Ressource MUSS nach Erkennung der Fehlersituation freigegeben werden. Ein manuelles Eingreifen DARF NICHT erforderlich sein.

    <=

    TIP1-A_5408

    Der Konnektor MUSS beim Anfordern und Auswerfen von Karten die folgenden Display-Nachrichten für die Anzeige im Kartenterminal verwenden, wenn der Aufrufer keine konkrete Display-Nachricht übergeben hat. Der Verweis auf den Kartenterminal-Slot SOLL in der Display-Nachricht entfallen, wenn es keine Slot-Auswahl am Kartenterminal gibt.

    Tabelle 32: TAB_KON_727 Terminalanzeigen beim Anfordern und Auswerfen von Karten

    Kontext
    Kartentyp
    Terminal-Anzeige
    Karte anfordern
    EGK
    Bitte•0x0BeGK•0x0Bin
    0x0BSLOT X0x0Bstecken

    HBA,
    HBAx,
    HBA-qSig

    Bitte•0x0BHBA•0x0Bin
    0x0BSLOT X0x0Bstecken

    SMC-B
    Bitte•0x0BSMC-B•0x0Bin
    0x0BSLOT X0x0Bstecken

    sonstiger
    Kartentyp
    oder kein explizit angegebener Kartentyp

    Bitte•0x0BKarte•0x0Bin
    0x0BSLOT X0x0Bstecken

    Karte auswerfen
    EGK
    Bitte•0x0BeGK•0x0Baus
    0x0BSLOT X0x0Bentnehmen

    HBA,
    HBAx,
    HBA-qSig

    Bitte•0x0BHBA•0x0Baus
    0x0BSLOT X0x0Bentnehmen

    SMC-B
    Bitte•0x0BSMC-B•0x0Baus
    0x0BSLOT X0x0Bentnehmen

    sonstiger
    Kartentyp
    oder kein explizit angegebener Kartentyp

    Bitte•0x0BKarte•0x0Bentnehmen
    <=

    4.1.4.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_4540

    Der Konnektor MUSS Service Announcement für das Auffinden von Kartenterminals entsprechend [SICCT] und [gemSpec_KT] unterstützen. Der Konnektor MUSS Dienstbeschreibungspakete auf UDP Port CTM_SERVICE_ANNOUNCEMENT_PORT entgegennehmen.

    Erhält er ein solches Dienstbeschreibungspaket, MUSS er

    <=

    TIP1-A_4541

    Der Kartenterminaldienst MUSS auf SICCT-Ereignisnachrichten „Slot-Ereignis – Karte eingesteckt“ ([SICCT#6.1.4.4], TAG ‚84’) wie folgt reagieren:

    <=

    TIP1-A_4542

    Der Kartenterminaldienst MUSS auf SICCT-Ereignisnachrichten „Slot-Ereignis – Karte entfernt“ ([SICCT#6.1.4.4], TAG ‚85’) wie folgt reagieren:

    <=

    TIP1-A_4543

    Tritt der Event "KSR/UPDATE/START" mit „Target=KT“ ein, MUSS der Konnektor:

    <=

    TIP1-A_4544

    Tritt der Event "KSR/UPDATE/END" mit „Target=KT“ ein, MUSS der Konnektor:

    <=

    4.1.4.3 Interne TUCs, nicht durch Fachmodule nutzbar
    4.1.4.3.1 TUC_KON_050 „Beginne Kartenterminalsitzung“

    TIP1-A_4545-03

    Der Konnektor MUSS den technischen Use Case „Beginne Kartenterminalsitzung” gemäß TUC_KON_050 umsetzen.

    Tabelle 33: TAB_KON_039 – TUC_KON_050 „Beginne Kartenterminalsitzung“

    Element
    Beschreibung
    Name
    TUC_KON_050 „Beginne Kartenterminalsitzung“
    Beschreibung

    TUC_KON_050 baut eine TLS-Verbindung vom Konnektor zum Kartenterminal auf und beginnt eine SICCT-Sitzung. Anschließend erfolgt die 2. Authentifizierung des Kartenterminals (Prüfung SharedSecret).
    Auslöser

    • Neustart des Konnektors
    • nach dem Setzen eines Kartenterminals auf „aktiv“
    • im Rahmen eines erneuten Verbindungsversuchs
    Vorbedingungen
    ctId ist in CTM_CT_LIST vorhanden
    Eingangsdaten

    • ctId
      (zu verbindendes Kartenterminal)
    • role
      (Benutzerrolle; gültig sind: „User“ und „Admin“)
    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
    keine
    Nachbedingungen

    • TLS-Kanal und SICCT-Session mit gewünschter Benutzerrolle
      aufgebaut, wenn CT.CORRELATION >= "gepairt"
    • TLS-Kanal und SICCT-Session mit leerem Username, Password
      und Session ID aufgebaut, wenn CT.CORRELATION <=
      „zugewiesen“
    • Steck-Ereignisse für alle im KT befindlichen Karten ausgelöst, wenn
      CT.CORRELATION>=„gepairt“
    Standardablauf

    Setze CT = CTM_CT_LIST(ctId)
    1.       Wenn CT.IS_PHYSICAL = Nein:
           prüfen, ob role = „User“
                          Wenn CT.CONNECTED =
                                       Ja: TUC endet erfolgreich
                                       Nein:
                                          - Verbindung zu HSM in Slot 1 aufbauen
                                          - weiter mit Schritt 9
    2.       Wenn CT.CONNECTED = Ja
          prüfen, ob CT.ACTIVEROLE = role
                          Ja: TUC endet erfolgreich
                          Nein:
                             - Schließen der Cardterminal Session mit dem
                                 Kartenterminalkommando SICCT CLOSE CT
                                 SESSION,
                            - weiter ab Schritt 6 (halten der TLS-Verbindung und
                                 nur Wechsel der Session)
    3.       Aufbau einer TLS-Verbindung mit dem Kartenterminal unter
        Verwendung von ID.SAK.AUT. Dabei Prüfung des KT-Zertifikats
       mittels
        TUC_KON_037 {
              certificate= C.SMKT.AUT;
              qualifiedCheck=not_required;
              offlineAllowNoCheck=true;
              policyList= oid_smkt_aut;
              intendedKeyUsage= intendedKeyUsage(C.SMKT.AUT);
              intendedExtendedKeyUsage=id-kp-serverAuth;
              validationMode=NONE }
    4.       Wenn CT.CORRELATION <=„zugewiesen“:
         a.              Öffne eine Cardterminal Session mit dem
                 Kartenterminalkommando SICCT INIT CT SESSION (siehe
                [SICCT#5.10]) mit leerem Username, Password und Session
                ID
         b.              Nur Verbindung in niedriger Korrelation, daher setze
                 CT.CONNECTED = Nein, um fachliche Nutzung des KT zu
                 verhindert
         c.              beende TUC erfolgreich
    5.       Prüfe, ob das Zertifikat aus der TLS-Verbindung mit den zum
        Kartenterminal gespeicherten Referenzdaten (CT.SMKT_AUT)
       übereinstimmt.
         a.  Läuft das Zertifikat CT.SMKT_AUT (oder C.SMKT.AUT, sie müssen hier identisch sein) in weniger als 35 Tagen ab, so geht der Konnektor in den Betriebszustand
    EC_CardTerminal_gSMC-KT_Certificate_Expires_Soon (ctId) über.
    6.       Parallelisierung
         a.              Generierung eines zufälligen Werts (Challenge) mit
                 mindestens 16 Byte Länge gemäß [gemSpec_Krypt#2.2]
                (siehe [gemSpec_KT#DO_KT_0004]),
         b.              Öffnen einer Cardterminal Session mit dem
                Kartenterminalkommando SICCT INIT CT SESSION (siehe
                [SICCT#5.10]) mit
                          -               ctId als Adressat
                          -               Wenn role = User
                                   dann mit leerem Username, Password und
                                  Session ID
                            Wenn role = „Admin
                                   dann mit leerer Session ID aber mit
                                  CT.ADMIN_USERNAME und
                                   CT.ADMIN_PASSWORD
    7.       Senden der Challenge mittels Kartenterminalkommando
        EHEALTH TERMINAL AUTHENTICATE (siehe
       [gemSpec_KT#3.7.2]) in der Ausprägung VALIDATE mit:
          -               Kartenterminal als Empfänger
          -               und mit der in Schritt 6a generierten Challenge im
                Shared Secret Challenge DO
    8.       Prüfe Antwort des Kartenterminals, ob sie einen korrekten
        Hashwert über Challenge und angehängtes
       CT.SHARED_SECRET gemäß [gemSpec_KT#SEQ_KT_0002]
        Schritt 4-5 enthält
    9.       Setze:
          a.             CT.ACTIVEROLE = $role
          b.             CT.CONNECTED = Ja
    10 .     Wenn TLS-Verbindung neu aufgebaut werden musste, rufe
         TUC_KON_256 {
               topic = „CT/CONNECTED“;
               eventType = „Op“;
               severity = Info;
               parameters = („CtID=$CT.CTID,
                     Hostname=$CT.HOSTNAME“) }
    11.      Ermittle alle im KT gesteckten Karten und befülle entsprechend
           CT.SLOTS_USED
    Für jeden in CT.SLOTS_USED gelisteten Slot X zur weiteren internen
    Bearbeitung TUC_KON_256{
         topic = „CT/SLOT_IN_USE“;
         eventType = Op;
         severity = Info;
         parameters = („CtID=$CT.CTID, SlotNo=$CT.SLOTS_USED[X]“);
         doLog = false;
         doDisp = false }
    rufen.
    Varianten/
    Alternativen
    Keine.

    Fehlerfälle

    Fehler in den folgenden Schritten des Ablaufs führen zu:
    Aufruf von TUC_KON_256 {
          topic = "CT/TLS_ESTABLISHMENT_FAILURE";
          eventType = $ErrorType;
          severity = $Severity;
          parameters = („CtID=$CT.ID, Name=$CT.HOSTNAME,
                                Error=$Fehlercode, Bedeutung=$Fehlertext“) }
    Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes

    (1): Admin-Rolle für logische KTs nicht möglich (hätte bei korrekter
    Implementierung nicht stattfinden dürfen), Fehlercode: 4032
    (1): Verbindungsaufbau zu HSM fehlgeschlagen, Fehlercode: 4032
    (3): Fehler im TLS-Verbindungsaufbau bzw. Zertifikatsprüfung,
    Fehlercode: 4028
    und setze CT.CONNECTED auf „Nein“
    (3): TLS-Verbindung konnte nicht innerhalb von
    CTM_TLS_HS_TIMEOUT Sekunden aufgebaut werden , Fehlercode:
    4028 und setze CT.CONNECTED auf „Nein“
    (5): Präsentiertes Zertifikat nicht das aus dem Pairing, Fehlercode:
    4029
    und setze CT.CORRELATION auf „gepairt“
    und setze CT.CONNECTED auf „Nein“
    und terminiere TLS-Verbindung
    (6b): Hinterlegte KT-Admin-Credentials fehlerhaft, Fehlercode: 4030
    und in die User-Session zurückzuwechseln (damit das KT für den
    normalen Fachbetrieb weiterhin zur Verfügung steht)
    (8): Prüfung auf Nachweis SharedSecret fehlgeschlagen, Fehlercode
    4029
    und setze CT.CORRELATION auf „gepairt“
    und setze CT.CONNECTED auf „Nein“
    und terminiere TLS-Verbindung
    Nichtfunktionale
    Anforderungen
    keine

    Zugehörige
    Diagramme
    Abbildung PIC_KON_110 Aktivitätsdiagramm zu „Beginne
    Kartenterminalsitzung



    Abbildung 8: PIC_KON_110 Aktivitätsdiagramm zu „Beginne Kartenterminalsitzung“

    Tabelle 34: TAB_KON_523 Fehlercodes TUC_KON_050 „Beginne Kartenterminalsitzung“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4028
    Technical
    Error
    Fehler beim Versuch eines Verbindungsaufbaus zu KT
    4029
    Security
    Error
    Fehler bei der KT-Authentisierung. KT möglicherweise manipuliert
    4030
    Security
    Error
    Admin-Werte für KT fehlerhaft
    4032
    Technical
    Error
    Verbindung zu HSM konnte nicht aufgebaut werden
    <=

    4.1.4.3.2 TUC_KON_054 „Kartenterminal hinzufügen“

    TIP1-A_4546

    Der Konnektor MUSS den technischen Use Case TUC_KON_054 „Kartenterminal hinzufügen“ umsetzen.

    Tabelle 35: TAB_KON_524 – TUC_KON_054 „Kartenterminal hinzufügen“

    Element
    Beschreibung
    Name
    TUC_KON_054 „Kartenterminal hinzufügen“
    Beschreibung
    Dieser TUC nimmt ein neues Kartenterminal in die zentrale Verwaltung auf (CTM_CT_LIST) oder aktualisiert die Einträge zu einem bereits erfassten Kartenterminal.
    Auslöser
    • ein empfangenes Dienstbeschreibungspaket ohne vorheriges Service Discovery
    • manuelles Hinzufügen eines KT-Eintrags
    • ein empfangenes Dienstbeschreibungspaket nach vorherigem Auslösen eines manuellen Service Discovery
    Vorbedingungen
    •     entweder ist das KT noch nicht in CTM_CT_LIST enthalten
    •     oder das KT ist unter anderer IP/anderem Hostnamen schon gelistet
    Eingangsdaten
    •     Mode (AutoAdded, ManuallyAdded, ManuallyModified)
    •     IP-Adresse (IPv4)
    •     TCP-Port (optional)
    •     MAC-Adresse (optional)
    •     Hostname (optional)
    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
    • keine
    Nachbedingungen
    • Das Kartenterminal ist mit allen Gerätekenndaten in CTM_CT_LIST vorhanden
    Standardablauf
    1.   Sofern optionale Parameter nicht übergeben wurden oder
          Mode<>AutoAdded, ermittle Port, MAC und Hostname via Service
          Discovery als UDP/IP-Unicast an IP-Adresse und Port
          CTM_SERVICE_DISCOVERY_PORT
    2.   Finde CT in CTM_CT_LIST über MAC-Adresse
    3.   Wenn MAC-Adresse nicht in CTM_CT_LIST:
    a)         Erzeuge neuen CT-Object-Eintrag in CTM_CT_LIST und
                  -                Generiere eindeutige CT.CTID
                  -                setzte CT.MAC_ADRESS auf MAC-Adresse
                  -                Setze CT.CORRELATION =„bekannt“
                  -                Setze CT.CONNECTED = „Nein“
    b)         Wenn Mode= ManuallyAdded setze CT.CORRELATION
           =„zugewiesen“
    4.   Wenn CT.CONNECTED = Ja und (IP-Adresse <> CT.IP_ADRESS
          oder TCP-Port <> CT.TCP_PORT),
          beende TLS-Verbindung und setze CT.CONNECTED = „Nein“
    5.  Befülle: CT.IP_ADRESS, CT.Hostname, CT.TCP_PORT
    6.  Wenn CT.CORRELATION>=„zugewiesen“ rufe TUC_KON_055
         „Befülle CT-Object“
    Varianten/
    Alternativen
    Keine
    Fehlerfälle
    Fehler im Ablauf (Standardablauf oder Varianten) führen in den folgend ausgewiesenen Schritten zu einem Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes:

    (1)  Keine Antwort innerhalb CTM_SERVICE_DISCOVERY_TIMEOUT,
              Fehlercode: 4033
    (1)  Ermittelte MAC-Adresse weicht von übergebener MAC-Adresse
              ab, Fehlercode: 4035
    (1)  Ermittelter Hostname-Adresse weicht von übergebenem Hostname
             ab, Fehlercode: 4036
    (2)  Wenn Mode=ManuallyModified und nicht gefunden, Fehlercode:
              4037
    Zusätzlich im Abbruchfall:
    -        Aufruf von TUC_KON_256 {
             topic = "CT/CT_ADDING_ERROR"; 
             eventType = $ErrorType;
             severity = $Severity;
             parameters = („IP=$IP-Adresse, Name=$HOSTNAME,
                Error=$Fehlercode, Bedeutung=$Fehlertext“) }
    -        Keine Veränderung an CTM_CT_LIST
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige
    Diagramme
    keine

    Tabelle 36: TAB_KON_525 Fehlercodes TUC_KON_054 „Kartenterminal hinzufügen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4033
    Technical
    Error
    Kartenterminal antwortet nicht, Zufügen fehlgeschlagen
    4035
    Technical
    Error
    Angegebener IP-Adresse gehört zu einer anderen MAC-Adresse als die, die übergeben wurde. Angaben zur MAC prüfen
    4036
    Technical
    Error
    Angegebener IP-Adresse gehört zu einem anderen Hostname als der, der übergeben wurde. Angaben zum Hostname prüfen
    4037
    Technical
    Error
    Verwaltung der Kartenterminals inkonsistent
    <=

    4.1.4.3.3 TUC_KON_053 „Paire Kartenterminal“

    TIP1-A_4548-02

    Der Konnektor MUSS den technischen Use Case „Paire Kartenterminal” gemäß TUC_KON_053 umsetzen.

    Tabelle 37: TAB_KON_041 – TUC_KON_053 „Paire Kartenterminal“

    Element
    Beschreibung
    Name
    TUC_KON_053 „Paire Kartenterminal“
    Beschreibung
    TUC_KON_053 führt das Pairing zwischen dem Konnektor und einem eHealth-Kartenterminal durch.
    Auslöser
    Dialoge zur Administration des Konnektors. Der Administrator hat ein Kartenterminal im Dialog der Managementschnittstelle ausgewählt und das Pairing aufgerufen.
    Vorbedingungen
    • KT ist in CTM_CT_LIST vorhanden
    • CT.CORRELATION = „zugewiesen“
    • CT.IS_PHYSICAL = Ja
    Eingangsdaten
    • ctId
    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
    • Keine
    Nachbedingungen
     -  CT.CORRELATION = „aktiv“, wenn Pairing erfolgreich
      - CT.CORRELATION = „zugewiesen“, wenn Pairing nicht erfolgreich
     -  CT.CONNECTED = „Ja“, wenn Pairing erfolgreich
    Standardablauf
    Setze CT = CTM_CT_LIST(ctId)
    1.   Prüfe CT.VALID_VERSION = true
    2.   Aufbau einer TLS-Verbindung mit dem Kartenterminal unter
          Verwendung von ID.SAK.AUT. Dabei:
      a.           Speichern des präsentierten KT-Zertifikats in
            CT.SMKT_AUT
      b.           Prüfung des KT-Zertifikats mittels TUC_KON_037{
                       certificate = C.SMKT.AUT;
                       qualifiedCheck = not_required;
                       offlineAllowNoCheck = true;
                       policyList = oid _smkt_aut;
                       intendedKeyUsage= intendedKeyUsage(C.SMKT.AUT);
                       intendedExtendedKeyUsage = id-kp-serverAuth;
                       validationMode = NONE }
    3.   Der Konnektor entnimmt den Fingerprint dem KT-Zertifikat und stellt
          dies dem Administrator im Dialog der Managementschnittstelle dar.
          Der Konnektor fordert den Administrator auf, den Fingerprint zu
          akzeptieren oder zurückzuweisen.
    4.  Wenn der Administrator den Fingerprint bestätigt,
            a.             generiert der Konnektor einen neuen Schlüssel, das
                  Shared Secret ShS.KT.AUT gemäß [gemSpec_Krypt#2.2]
                  (siehe [gemSpec_KT#3.7]) und speichert es in
                  CT.SHARED_SECRET
            b.            und eröffnet der Konnektor mit dem
                  Kartenterminalkommando SICCT INIT CT SESSION (siehe
                  [SICCT#5.10]) mit
                           -             ctId als Adressat
                           -             und mit leerem Username, Password und
                             Session ID
                 eine Cardterminal Session.
    5.   Der Konnektor sendet mittels Kartenterminalkommando EHEALTH
          TERMINAL AUTHENTICATE (siehe [gemSpec_KT#3.7.2]) in der
          Ausprägung CREATE mit
             -           ctId als Empfänger
             -           und mit dem in Schritt 4.a generierten Schlüssel im
                Shared Secret DO und der Display Message
                „KT:$CT.MAC_ADRESS MIT
          KON:$MGM_KONN_HOSTNAME PAIREN OK?“, wobei die
                 MAC-Adresse mit Trenner im folgenden Format dargestellt
                 werden MUSS: „AABBCC:DDEEFF“
     das Shared Secret an das Kartenterminal.
    6.   Der Konnektor prüft ob in der Antwort des Kartenterminals eine
          korrekte Signatur des Shared Secrets gemäß
         [gemSpec_KT#SEQ_KT_0001] Schritt 7, ausgeführt mit dem
         Schlüssel zum Zertifikat CT.SMKT_AUT vorliegt.
    7.  CT.CORRELATION wird auf „gepairt“ gesetzt
    8.   TLS-Verbindung, die zum Pairen diente, beenden und zuvor das
          Kartenterminalkommando SICCT CLOSE CT SESSION mit ctId als
          Adressat senden
    9.   Automatischer Zustandsübergang CT.CORRELATION = „gepairt“
          nach „aktiv“ (implizite Aktion des Administrators durch Aufruf von
         TUC_KON_053).
    10. „Arbeits“-TLS-Verbindung neu aufbauen durch Aufruf
          TUC_KON_050 { ctId; role = „User“}
    Varianten/
    Alternativen
    (4): weist der Administrator den Fingerprint in Schritt 3 ab, wird
            TUC_KON_053 nach Ausführung folgender Aktivitäten beendet:
       4.1.a)    Löschen von CT.SMKT_AUT
       4.1.b)    Abbau der TLS-Verbindung, Setzen von CT.CONNECTED
                    auf „Nein“
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu:
      a)             Aufruf von TUC_KON_256 {
                       topic = "CT/ERROR";
                       eventType = $ErrorType;
                       severity = $Severity;
                       parameters = („CtID=$ctId, Name=$CT.HOSTNAME,
                          Error=$Fehlercode,
                          Bedeutung=$Fehlertext“);
                       doDisp = false }
      b)              Löschen von CT.SMKT_AUT, CT.SHARED_SECRET
      c)              Direkte Anzeige der Fehlermeldung für den Administrator
      d)              Abbruch der Verarbeitung mit den ausgewiesenen
             Fehlercodes

    (1) Version des KT wird nicht unterstützt, Fehlercode: 4042
    (2b) Zertifikat ist zeitlich nicht gültig,
             Fehlercode: 1021 (CERTIFICATE_NOT_VALID_TIME)
    (
    2) Fehler im TLS Verbindungsaufbau bzw. Zertifikatsprüfung,
             Fehlercode: 4040
    (4b) Fehler in SICCT INIT CT SESSION, Fehlercode: 4041 mit
            Angabe des SICCT-Fehlers
    (5) Fehler in EHEALTH TERMINAL AUTHENTICATE, Fehlercode:
             4041 mit Angabe des SICCT-Fehlers
    (6) Signaturprüfung fehlgeschlagen, Fehlercode: 4041
    Zugehörige
    Diagramme
    Siehe PIC_KON_057

    Tabelle 38: TAB_KON_113 Fehlercodes TUC_KON_053 „Paire Kartenterminal“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4040
    Security
    Error
    Fehler beim Versuch eines Verbindungsaufbaus zum KT
    4041
    Technical
    Error
    Fehler im Pairing, SICCT-Fehler(Nur wenn dieser Fehler wegen eines Fehlers auf der SICCT-Schnittstelle auftritt, ist der SICCT-Fehlercode mit anzugeben.): <SICCT-Fehler>
    4042
    Technical
    Error
    Die Version des Kartenterminals wird nicht unterstützt
    Hinweis zu Fehler 4041:
    Nur wenn dieser Fehler wegen eines Fehlers auf der SICCT-Schnittstelle auftritt, ist der SICCT-Fehlercode mit anzugeben.

    Abbildung 9: PIC_KON_057 Aktivitätsdiagramm zu „PaireKartenterminal“

    <=

    4.1.4.3.4 TUC_KON_055 „Befülle CT-Object“

    TIP1-A_4985

    Der Konnektor MUSS den technischen Use Case TUC_KON_055 „Befülle CT-Object“ umsetzen.

    Tabelle 39: TAB_KON_526 – TUC_KON_055 „Befülle CT-Object“

    Element
    Beschreibung
    Name
    TUC_KON_055 „Befülle CT-Object“
    Beschreibung
    Dieser TUC befüllt ein vorhandenes CT-Object aus CTM_CT_LIST mit den aktuellen Produktinformationen, die vom Kartenterminal bezogen werden und prüft, ob die Version des Kartenterminals unterstützt wird.
    Auslöser
    • TUC_KON_054
    • Ereignis „KSR/UPDATE/END“ mit „Target=KT“
    • Verändern von CT.CORRELATION auf „zugewiesen“
    • Administratoraktion
    Vorbedingungen
    • ctId ist in CTM_CT_LIST vorhanden
    Eingangsdaten
    • ctId
    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
    • Supported (Boolean, True, wenn die Version des KT unterstützt wird)
    Nachbedingungen
    • Die Gerätekenndaten des Kartenterminals in CTM_CT_LIST sind aktualisiert
    Standardablauf
    Setze CT = CTM_CT_LIST(ctId)
    1. Wenn CT.CONNECTED=Nein: Rufe TUC_KON_050 {
          ctId,
          role = „User” }

    2. Folgende CT.Werte via SICCT GET STATUS ermitteln und befüllen:
      •    CT.SLOTCOUNT 
      •    CT.PRODUCTINFORMATION
      •    CT.EHEALTH_INTERFACE_VERSION (Element VER aus Discretionary Data Data Object (DD DO))
      •    CT.DISPLAY_CAPABILITIES (aus Display Capabilities Data Object in [SICCT#5.5.10.17])
    3. Finde Eintrag in CTM_SUPPORTED_KT_VERSIONS anhand der ersten beiden Stellen (Haupt- und Nebenversionsnummer) aus
      CT.EHEALTH_INTERFACE_VERSION

        Eintrag gefunden:         Die dritte Stelle der KT-Version ist im Vergleich
                                             zur dritten Stelle im gefundenen Eintrag:

                                                  >=:    Setze Result = True
                                                  <:    Setze Result = False
        Kein Eintrag gefunden: Setze Result = False
    1. Setze CT.VALID_VERSION auf Result
    2. Wenn Verbindung in (1) aufgebaut wurde, trenne Verbindung
    3. Liefere Result zurück
    Varianten/
    Alternativen

    (->5) Wenn CT.CORRELATION="aktiv", kann die in (1) aufgebaute Verbindung bestehen bleiben.
    Fehlerfälle
    -> 2) Kartenterminal antwortet mit einer spezifischen Fehlermeldung, Fehlercode <gemäß [SICCT]>
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    keine

    <=

    4.1.4.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.4.4.1 TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“

    TIP1-A_4547

    Der Konnektor MUSS den technischen Use Case „Mit Anwender über Kartenterminal interagieren” gemäß TUC_KON_051 umsetzen.

    Tabelle 40: TAB_KON_112 – TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“

    Element
    Beschreibung
    Name
    TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“
    Beschreibung
    Der TUC ermöglicht es, Meldungen an das Display eines Kartenterminals zu senden oder Eingaben vom Benutzer über das PIN-Pad eines Kartenterminals abzufragen (unter Anzeige einer Meldung).
    Auslöser
    Fachmodul im Konnektor oder anderer technischer Use Case ruft diesen Use Case auf.
    Vorbedingungen
      • KT ist in CTM_CT_LIST vorhanden
      • CT.CORRELATION = „aktiv“
      • CT.CONNECTED = Ja
      • CT.IS_PHYSICAL = Ja
    Eingangsdaten
      • ctId
        (Kartenterminalidentifikator)

      • displayMessage – optional/nicht erforderlich bei opmode=  OutputErase, sonst mandatory
        (Text zur Darstellung am KT, Länge durch KT begrenzt);

      • opMode [KtOutputMode]
        (Kommando-Modus)

      • inputLength – optional/nur bei opMode=Input
        (erwartete Eingabelänge, 0 für „beliebig“ lang)

      • waitTimer – optional/nur bei opMode=OutputWait
        (Wartezeit bis zur ersten Eingabe in Sekunden)

    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
      • opResult [OK | ABBRUCH ] – optional/verpflichtend, wenn opMode=Input oder opMode=OutputConfirm
        (Nutzertastendruck)
      • inputData – optional/nur bei opMode = Input
        (Zifferneingabe des Benutzers)

    Nachbedingungen
    Wenn Mode=OutputKeep bleibt Data auf dem Display des KT stehen
    Standardablauf
    Setze CT = CTM_CT_LIST(ctId)
    1. opMode=
      1.           Input:
        Der Konnektor MUSS via SICCT INPUT am CT zur Eingabe auffordern. Dabei MUSS die KT-Ansteuerung so erfolgen, dass:

        • displayMessage zur Anzeige gebracht wird
        • maximal inputLength Ziffern akzeptiert werden. Bei inputLength=0 werden 1-n Zeichen akzeptiert (n=Maximalwert, definiert durch KT)
        • die eingegebenen Zeichen am Display angezeigt werden
        • die Eingabe explizit mit OK oder ABBRUCH beendet werden muss
      2.           OutputWait:
        Der Konnektor MUSS via SICCT OUTPUT am CT displayMessage zur Anzeige bringen. Nach einer Wartezeit von waitTimer Sekunden MUSS der Konnektor die Anzeige des KT leeren.
      3.           OutputConfirm:
        Der Konnektor MUSS via SICCT INPUT am CT displayMessage zur Anzeige bringen und auf eine Bestätigung durch den Nutzer warten (zulässig: OK, ABBRUCH)

      4.           OutputKeep:
        Der Konnektor MUSS via SICCT OUTPUT am CT displayMessage zur Anzeige bringen. Die Anzeige bleibt erhalten, bis das KT neue Informationen am Display darstellen muss/soll.

      5.           OutputErase:
        Der Konnektor MUSS via SICCT OUTPUT am CT die Anzeige leeren.

    Varianten/
    Alternativen

    • Ist das Kartenterminal-Display durch einen anderen, zeitgleich im Konnektor ablaufenden Vorgang reserviert, so muss der Konnektor zunächst maximal 10 Sekunden lang versuchen, Zugriff auf das Display zu erhalten (und somit parallele Zugriffe auf das Display zu serialisieren). Erst nach Ablauf der Wartezeit wird Fehler 4039 geworfen.
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zum Aufruf von TUC_KON_256 {
          topic = "CT/ERROR";
          eventType = $ErrorType;
          severity = $Severity;
          parameters = („CtID=$ctId, Name=$CT.HOSTNAME,
                                Error=$Fehlercode, Bedeutung=$Fehlertext“) }


    (1) Display und PinPad des Kartenterminals sind aktuell belegt (PIN,
            Eingabe, andere Ausgabe etc.), Fehlercode: 4039

    (1) Kartenterminal antwortet mit einer spezifischen Fehlermeldung,
             Fehlercode <gemäß [SICCT]>

    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 41: TAB_KON_114 Fehlercodes TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4039
    Technical
    Error
    Kartenterminal durch andere Nutzung aktuell belegt

    <=

    4.1.4.4.2 TUC_KON_056 „Karte anfordern“

    TIP1-A_5409

    Der Konnektor MUSS den technischen Use Case „Karte anfordern” gemäß TUC_KON_056 umsetzen.

    Tabelle 42: TAB_KON_723 - TUC_KON_056 „Karte anfordern“

    Element
    Beschreibung
    Name
    TUC_KON_056 „Karte anfordern“
    Beschreibung
    Der TUC ermöglicht es, die Aufforderung zum Karte-Stecken an das Kartenterminal zu senden und dabei eine Meldung zum Anzeigen im Display des Kartenterminals mitzugeben.
    Auslöser
    Fachmodul im Konnektor oder Operation RequestCard ruft diesen Use Case auf.
    Vorbedingungen

    Eingangsdaten
    -      ctId
         (Kartenterminalidentifikator)
    - slotId
        (Nummer des Kartenslots)
      -   cardType - optional
    - displayMessage – optional  
        (Text zur Darstellung am Kartenterminal, Länge durch KT begrenzt)
    -     timeOut
        (Wartezeit in Sekunden)

    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
      • cardObject
        (Informationsobjekt der Karte)
    Nachbedingungen
    Im Erfolgsfall enthält die CM_CARD_LIST ein neues CARD-Objekt des geforderten Typs.
    Standardablauf
    Setze CT = CTM_CT_LIST(ctId)
    1.      Falls displayMessage nicht explizit angegeben ist, MUSS sie gemäß Anforderung [TIP1-A_5408] erstellt werden.
    2.      Der Konnektor MUSS das Kommando SICCT REQUEST ICC an das Kartenterminal CT senden. Die verfügbaren Optionen (Optical Signal, Acoustic Signal) können herstellerspezifisch sein bzw. über die Konfigurationsschnittstelle des Konnektors eingestellt werden. displayMessage wird als Eingabeaufforderung mitgegeben. Der übergebene timeOut-Wert wird dem SICCT-Kommando als Parameter übergeben.
    3.      Falls die Karte noch nicht gesteckt war, wird durch das Stecken der Karte das Ereignis „Karte gesteckt“ ausgelöst, worauf der Konnektor reagiert [TIP1-A_4563].
    4.      Die Verarbeitung wird fortgesetzt, wenn eines der Ereignisse eingetreten ist:
      1.        SICCT REQUEST ICC kehrt mit '6201' zurück (eine aktivierte Karte steckte bereits)
      2.       SICCT REQUEST ICC kehrt mit '9000' oder '9001' zurück und das Ereignis "Karte gesteckt" wurde gemäß [TIP1-A_4563] verarbeitet
      3.       SICCT REQUEST ICC kehrt mit '9000' oder '9001' zurück und das Ereignis "Karte gesteckt" wurde nicht empfangen (eine deaktivierte Karte steckte bereits), die Karte wurde durch
              Rufe TUC_KON_001 {
                    ctId; slotId }
        geöffnet.
    In allen Fällen liegt in CM_CARD_LIST ein neues CARD-Objekt vor.
    1.      Falls cardType angegeben ist, wird nach erfolgreicher Ausführung von SICCT REQUEST ICC der AID des MF der gesteckten Karte gelesen und mit dem gewünschten Kartentyp in cardType verglichen. Bei fehlender Übereinstimmung wird der Ablauf mit dem Fehler 4051 abgebrochen.
    2.      Es wird cardObject (ein Informationsobjekt der Karte, die sich in dem Slot mit der Nummer slotId befindet) zurückgegeben.
    Varianten/
    Alternativen
    Die Ausgabe einer Display-Nachricht entfällt, wenn der adressierte Slot bereits eine gesteckte Karte enthält.
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu Aufruf von TUC_KON_256 {
          topic = "CT/ERROR";
          eventType = $ErrorType;
          severity = $Severity;
          parameters = („CtID=$ctId, Name=$CT.HOSTNAME,
                                   Error=$Fehlercode, Bedeutung=$Fehlertext“) }

    (2)    Display des Kartenterminals ist aktuell belegt, Fehlercode: 4039
    (2)    Fehler beim Zugriff auf das Kartenterminal, Fehlercode: 4044
    (2)    Ungültige Kartenterminal-ID: Fehlercode: 4007
    (2)    Ungültige Kartenslot-ID: Fehlercode: 4097
    (2)    Kartenterminal nicht aktiv, Fehlercode: 4221
    (2)    Kartenterminal ist nicht verbunden, Fehlercode: 4222
    (2)    Kartenterminal antwortet mit einer spezifischen Fehlermeldung,
               Fehlercode <gemäß [SICCT]>
    (4)    Timeout. Es wurde keine Karte innerhalb der angegebenen
               Zeitspanne gesteckt, Fehlercode: 4202
    (5)    Falscher Kartentyp, Fehlercode: 4051
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 43: TAB_KON_724 Fehlercodes TUC_KON_056 „Karte anfordern“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4039
    Technical
    Error
    Kartenterminal durch andere Nutzung aktuell belegt
    4044
    Technical
    Error
    Fehler beim Zugriff auf das Kartenterminal
    4051
    Technical
    Error
    Falscher Kartentyp
    4007
    Technical
    Error
    Ungültige Kartenterminal-ID
    4097
    Technical
    Error
    Ungültige Kartenslot-ID
    4202
    Technical
    Error
    Timeout. Es wurde keine Karte innerhalb der angegebenen Zeitspanne gesteckt.
    4221
    Technical
    Error
    Kartenterminal nicht aktiv
    4222
    Technical
    Error
    Kartenterminal ist nicht verbunden

    <=

    4.1.4.4.3 TUC_KON_057 „Karte auswerfen“

    TIP1-A_5410

    Der Konnektor MUSS den technischen Use Case „Karte auswerfen” gemäß TUC_KON_057 umsetzen.

    Tabelle 44: TAB_KON_725 – TUC_KON_057 „Karte auswerfen“

    Element
    Beschreibung
    Name
    TUC_KON_057 „Karte auswerfen“
    Beschreibung
    Der TUC ermöglicht es, das SICCT-Kommando zum Auswerfen der Karte an das Kartenterminal zu senden und dabei eine Meldung zum Anzeigen im Display des Kartenterminals mitzugeben, die den Benutzer zum Entnehmen der Karte auffordert.
    Auslöser
    Fachmodul im Konnektor oder Operation EjectCard ruft diesen Use Case auf.
    Vorbedingungen

    Eingangsdaten
      • ctId
        (Kartenterminalidentifikator)

      • slotId
        (Nummer des Kartenslots)

      • displayMessage – optional  
        (Text zur Darstellung am Kartenterminal, Länge durch KT begrenzt)

      • timeOut
        (Wartezeit in Sekunden)

    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
    keine
    Nachbedingungen
    Durch das Entfernen der Karte wird das Ereignis „Karte entfernt“ ausgelöst, worauf der Konnektor reagiert [TIP1-A_4562].
    Standardablauf
    Setze CT = CTM_CT_LIST(ctId)
    1.      Der Konnektor prüft, dass entweder die Karte nicht reserviert ist oder der Aufrufer im Besitz des Karten-Locks ist.
    2.      Falls displayMessage nicht explizit angegeben ist, MUSS sie gemäß Anforderung [TIP1-A_5408] erstellt werden.
    3.      Der Konnektor MUSS das Kommando SICCT EJECT ICC an das Kartenterminal CT senden. Der Aufruf MUSS mit der Option „Delivery: Mechanical Throwout“ erfolgen. Die anderen Optionen (Optical Signal, Acoustic Signal) können herstellerspezifisch eingestellt werden bzw. können über die Konfigurationsschnittstelle des Konnektors eingestellt werden. Der übergebene Wert timeOut wird dem SICCT-Kommando als Parameter übergeben.
    Varianten/
    Alternativen

    Auch im Falle, dass nach der internen Buchführung des Konnektors in dem angegebenen Slot des Kartenterminals keine Karte steckt, MUSS der Konnektor das SICCT-Kommando SICCT EJECT ICC an das Kartenterminal senden. Meldet das Kartenterminal keinen Fehler, so meldet auch der Konnektor keinen Fehler und es kann davon ausgegangen werden, dass sich keine Karte mehr in dem Slot befindet.
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu Aufruf von TUC_KON_256 {
          topic = "CT/ERROR";
          eventType = $ErrorType;
          severity = $Severity;
          parameters = („CtID=$CtID, Name=$CT.HOSTNAME,
                                   Error=$Fehlercode, Bedeutung=$Fehlertext“) }


    (1) Die Karte ist fremdreserviert, Fehlercode 4093
    (3) Display des Kartenterminals ist aktuell belegt, Fehlercode: 4039
    (3) Fehler beim Zugriff auf das Kartenterminal, Fehlercode: 4044
    (3) Karte deaktiviert, aber nicht entnommen, Fehlercode: 4203
    (3) Ungültige Kartenterminal-ID: Fehlercode: 4007
    (3) Ungültige Kartenslot-ID: Fehlercode: 4097
    (3) Kartenterminal nicht aktiv, Fehlercode: 4221
    (3) Kartenterminal ist nicht verbunden, Fehlercode: 4222
    (3) Kartenterminal antwortet mit einer spezifischen Fehlermeldung,
            Fehlercode <gemäß [SICCT]>

    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 45: TAB_KON_796 Fehlercodes TUC_KON_057 „Karte auswerfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4039
    Technical
    Error
    Kartenterminal durch andere Nutzung aktuell belegt
    4044
    Technical
    Error
    Fehler beim Zugriff auf das Kartenterminal
    4203
    Technical
    Error
    Karte deaktiviert, aber nicht entnommen
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4007
    Technical
    Error
    Ungültige Kartenterminal-ID
    4097
    Technical
    Error
    Ungültige Kartenslot-ID
    4221
    Technical
    Error
    Kartenterminal nicht aktiv
    4222
    Technical
    Error
    Kartenterminal ist nicht verbunden

    <=

    4.1.4.4.4 TUC_KON_058 „Displaygröße ermitteln“

    A_17473

    Der Konnektor MUSS den technischen Use Case „Displaygröße ermitteln“ gemäß TUC_KON_058 umsetzen.

    Tabelle 46: TAB_KON_854 – TUC_KON_058 „Displaygröße ermitteln“

    Element
    Beschreibung
    Name
    TUC_KON_058 „Displaygröße ermitteln“
    Beschreibung
    Der TUC liefert den Inhalt der Variable CT.DISPLAY_CAPABILITIES zurück.
    Auslöser
    Fachmodul im Konnektor ruft diesen Use Case auf.
    Vorbedingungen

    Eingangsdaten

    • ctId
      (Kartenterminalidentifikator)
    Komponenten
    Konnektor
    Ausgangsdaten
    CT.DISPLAY_CAPABILITIES
    Nachbedingungen
    Keine

    Standardablauf

    Setze CT = CTM_CT_LIST(ctId)
    1.      Der Konnektor prüft, ob CT.DISPLAY_CAPABILITIES belegt ist.
    2.      Falls CT.DISPLAY_CAPABILITIES belegt ist, wird der Inhalt der Variable zurückgegeben.
    Varianten/
    Alternativen
    Keine

    Fehlerfälle

    Fehler in den folgenden Schritten des Ablaufs führen zu Aufruf von TUC_KON_256 {
          topic = "CT/ERROR";
          eventType = $ErrorType;
          severity = $Severity;
          parameters = („CtID=$CtID, Name=$CT.HOSTNAME,
                                   Error=$Fehlercode, Bedeutung=$Fehlertext“) }

    (2) CT.DISPLAY_CAPABILITIES ist nicht belegt, Fehlercode 4254
    Nichtfunktionale Anforderungen
    Keine

    Zugehörige Diagramme
    Keine

    Tabelle 47: TAB_KON_855 Fehlercodes TUC_KON_058 „Displaygröße ermitteln“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4254
    Technical
    Error
    Keine Displaygröße für das Kartenterminal definiert
    <=

    4.1.4.5 Operationen an der Außenschnittstelle

    TIP1-A_5411-02

    Der Konnektor MUSS Clientsystemen den Basisdienst Kartenterminaldienst anbieten.

    Tabelle 48: TAB_KON_722 Basisdienst Kartenterminaldienst

    Name
    CardTerminalService
    Version (KDV)
    1.1.0 (WSDL-Version) 1.1.2 (XSD-Version)
    Namensraum
    Siehe GitHub
    Namensraum-Kürzel
    CT für Schema und CTW für WSDL
    Operationen
    Name
    Kurzbeschreibung
    RequestCard
    Karte anfordern
    EjectCard
    Karte auswerfen
    WSDL
    CardTerminalService.wsdl
    Schema
    CardTerminalService.xsd
    <=

    4.1.4.5.1 RequestCard

    TIP1-A_5412

    Der Konnektor MUSS an der Außenschnittstelle eine Operation RequestCard, wie in Tabelle TAB_KON_716 Operation RequestCard beschrieben, anbieten.

    Tabelle 49: TAB_KON_716 Operation RequestCard

    Name
    RequestCard
    Beschreibung
    Liefert die Information zu einer Karte, die in dem Slot eines Kartenterminals steckt oder innerhalb einer bestimmten Zeit (Timeout) gesteckt wird.
    Aufruf-parameter



    Name
    Beschreibung
    CCTX:Context
    MandantId, CsId, WorkplaceId verpflichtend
    CT:Slot
    Adressiert den Slot eines Kartenterminals über die Identifikation des Kartenterminal CARDCMN:CtId und die Nummer des Slots CARDCMN:SlotId
    CARDCMN:
    CardType
    Ein Kartentyp aus {EGK, KVK, HBAx, SM-B} als optionaler Filter. Wenn angegeben, werden nur Karten vom spezifizierten Typ zurückgegeben.
    CT:DisplayMsg
    Diese Nachricht wird am Display des Kartenterminals angezeigt, um den Nutzer zum Stecken der Karte aufzufordern.
    CT:TimeOut
    Die Zeit in sec, die maximal gewartet wird bis zum Stecken einer Karte. Wird dieser Parameter nicht übergeben, SOLL der Konnektor den Wert 20 sec verwenden. Optional KANN dieser Default-Wert im Konnektor konfigurierbar sein.
    Rückgabe
    Name
    Beschreibung
    CONN:Status
    Enthält den Ausführungsstatus der Operation (siehe 3.5.2)
    CT:AlreadyInserted
    Dieses optionale Flag gibt an, ob die Karte bereits vor der Anfrage steckte (Wert true) oder erst auf Anforderung dieses Aufrufs gesteckt wurde (Wert false oder Element nicht vorhanden).
    CARD:Card
    Falls eine Karte gesteckt ist, werden Information zur Karte zurückgegeben (siehe 4.1.6.5.2)
    Vorbedingung
    keine
    Nachbedingung keine
    Der Ablauf der Operation RequestCard ist in Tabelle TAB_KON_717 Ablauf RequestCard beschrieben.

    Tabelle 50: TAB_KON_717 Ablauf RequestCard

    Nr.

    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung

    1.


    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab. Wird die Operation für einen nicht unterstützten Kartentypen aufgerufen, so bricht die Operation mit Fehler 4058 ab.
    2.


    TUC_KON_000 „Prüfe Zugriffs-berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
          mandantId = $context.mandantId;
          clientSystemId = $context.clientsystemId;
          workplaceId = $context.workplaceId;
          ctId = $Slot.CtId;
          needCardSession=false;
          allWorkplaces=false }
    Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.
    3.


    TUC_KON_056 „Karte anfordern“


    Anforderung der Karte vom Kartenterminal durch Aufruf
    TUC_KON_056(
          ctId = $Slot.CtId;
          slotId = $Slot.SlotId;
          $cardType;
          displayMessage = $DisplayMsg;
          $timeOut)

    Tabelle 51: TAB_KON_718 Fehlercodes „RequestCard“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4058
    Security
    Error
    Aufruf nicht zulässig
    <=

    4.1.4.5.2 EjectCard

    TIP1-A_5413

    Der Konnektor MUSS an der Außenschnittstelle eine Operation EjectCard, wie in Tabelle TAB_KON_719 Operation EjectCard beschrieben, anbieten.

    Tabelle 52: TAB_KON_719 Operation EjectCard

    Name
    EjectCard
    Beschreibung
    Beendet die Kommunikation mit der Karte und wirft sie aus, falls das Kartenterminal eine solche mechanische Funktion hat.
    Aufruf-parameter



    Name
    Beschreibung
    Context
    MandantId, CsId, WorkplaceId verpflichtend
    CONN:
    CardHandle
    Adressiert die Karte, die ausgeworfen werden soll.
    CT:Slot
    Adressiert alternativ den Slot eines Kartenterminals, aus dem die Karte ausgeworfen werden soll. Die Adressierung erfolgt über die Identifikation des Kartenterminal CARDCMN:CtId und die Nummer des Slots CARDCMN:SlotId.
    CT:
    DisplayMsg
    Diese Nachricht wird am Display des Kartenterminals angezeigt, um den Nutzer zum entnehmen der Karte aufzufordern.
    CT:TimeOut
    Die Zeit in msec, die maximal gewartet wird bis eine Karte gezogen ist. Wird dieser Parameter nicht übergeben, SOLL der Konnektor den Wert 20 sec verwenden. Optional KANN dieser Default-Wert im Konnektor konfigurierbar sein.
    Rückgabe

    Name
    Beschreibung
    Status
    Enthält den Ausführungsstatus der Operation (siehe 3.5.2)
    Vorbedingung keine.
    Nachbedingung
    keine.
    Der Ablauf der Operation EjectCard ist in Tabelle TAB_KON_720 Ablauf EjectCard beschrieben.

    Tabelle 53: TAB_KON_720 Ablauf EjectCard

    Nr.

    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.

    TUC_KON_000 „Prüfe Zugriffs-berechtigung“
    Ist $cardHandle vorgegeben, so wird $ctId als Id des Kartenterminals bestimmt, in dem die Karte steckt.
    Prüfung der Zugriffsberechtigung durch den Aufruf TUC_KON_000 {
          mandantId = $Context.MandantId;
          clientSystemId = $Context.ClientSystemId;
          workplaceId = $Context.WorkplaceId;
          ctId = $Slot.CtId
                    bzw. ctId = CM_CARD_LIST($CardHandle).CTID;
          needCardSession = false;
          allWorkplaces = false }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3.


    TUC_KON_057 „Karte auswerfen“


    Wurde EjectCard mit dem Parameter Slot aufgerufen: Veranlassen des Kartenauswurfs am Kartenterminal durch Aufruf TUC_KON_057 {
          ctId = $Slot.CtId;
          slotId = $Slot.Slotid;
          displayMessage = $DisplayMsg;
          $timeOut }
    Wurde EjectCard mit dem Parameter CardHandle aufgerufen: Veranlassen des Kartenauswurfs am Kartenterminal durch Aufruf TUC_KON_057 {
          ctId = CM_CARD_LIST($CardHandle).CTID;
          slotId = CM_CARD_LIST ($CardHandle).SLOTNO; ;
          displayMessage = $DisplayMsg;
          $timeOut }

    Tabelle 54: TAB_KON_721 Fehlercodes Operation „EjectCard“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4203
    Technical
    Error
    Karte deaktiviert, aber nicht entnommen
    4101
    Technical
    Error
    Karten-Handle ungültig
    <=

    4.1.4.6 Betriebsaspekte
    4.1.4.6.1 Allgemeine Betriebsaspekte

    TIP1-A_4549

    Während des Bootvorgangs, nach dem Einlesen der persistierten Informationen des Kartenterminaldienstes MUSS der Konnektor für jedes Kartenterminal CT in CTM_CT_LIST:

    <=

    Hinweis: Bei der Initialiserung des Kartenterminaldienstes liest der Konnektor noch nicht die Karten, um zu ermitteln, welche Karten gesteckt sind. Dies erfolgt erst bei Initialisierung des Kartendienstes.

    TIP1-A_4550

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_527 vorzunehmen:

    Tabelle 55: TAB_KON_527 Konfigurationswerte eines Kartenterminalobjekts

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    CTM_SERVICE_DISCO
    VERY_PORT

    Portnummer
    Der Administrator MUSS die Portnummer eingeben können, auf der die KTs im lokalen Netz auf Dienstanfragen hören.
    Default-Wert=4742
    CTM_SERVICE_DISCO
    VERY_TIMEOUT

    X Sekunden
    Der Administrator MUSS die Anzahl Sekunden eingeben können, die der Konnektor auf Antworten zu Service-Discovery-Anfragen wartet.
    Default-Wert=3
    CTM_SERVICE_ANNOU
    NCEMENT_PORT

    Portnummer
    Der Administrator MUSS die Portnummer eingeben können, auf der der Konnektor auf Dienstbeschreibungspakete hört.
    Default-Wert=4742
    CTM_SERVICE_DISCO
    VERY_CYCLE

    X Minuten
    Der Administrator MUSS die Anzahl Minuten einstellen können, in denen der Konnektor wiederholt Service Discovery Nachrichten absetzt.
    Default-Wert=10,
    0=Deaktiviert
    CTM_KEEP_ALIVE_IN
    TERVAL


    X Sekunden

    Intervall in Sekunden in den Keep-Alive-Nachrichten an das Kartenterminal gesendet werden
    Der Administrator MUSS diesen Wert im vorgegebenen Bereich anpassen können.
    Wertebereich:1-10
    Default-Wert=10
    CTM_KEEP_ALIVE_TR
    Y_COUNT


    Anzahl der Versuche

    Anzahl von aufeinander folgenden, nicht beantworteten Keep-Alive-Nachrichten, nach denen ein Timeout der TLS-Verbindung festgestellt wird
    Der Administrator MUSS diesen Wert im vorgegebenen Bereich anpassen können.
    Wertebereich:3-10
    Default-Wert=3
    CTM_TLS_HS_TIMEOUT
    X Sekunden

    Der Administrator MUSS die Anzahl Sekunden eingeben können, die der Konnektor auf den TLS-Verbindungsaufbau zum Kartenterminal wartet (Handshake-Timeout).
    Wertebereich:1-60
    Default-Wert=10

    <=

    TIP1-A_4986

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen die Informationsparameter gemäß Tabelle TAB_KON_528 einzusehen:

    Tabelle 56: TAB_KON_528 Informationsparamter des Kartenterminaldienstes

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    CTM_SUPPORTED_KT_
    VERSIONS

    Liste von EHEALTH-Interface-Versionen
    Der Administrator MUSS die Liste der vom Konnektor unterstützten modellunabhängigen EHEALTH-Interface-Versionen einsehen können.

    <=

    4.1.4.6.2 Kartenterminals pflegen

    Im Folgenden werden die Administratorinteraktionen beschrieben, die zum Hinzufügen, Pairen, Bearbeiten und Löschen von Kartenterminals innerhalb der CTM_CT_LIST angeboten werden müssen. Eine Aktualisierung der Kartenterminals mit neuer Firmware wird in Kapitel 4.3.9 beschrieben.

    TIP1-A_4551

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen die Liste der verwalteten und neu entdeckten Kartenterminals einzusehen (CTM_CT_LIST).

    <=

    TIP1-A_4552

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu jedem CT-Object-Eintrag in CTM_CT_LIST mit CT.CONNECTED=Nein und CT.CORRELATION=aktiv einen manuellen Verbindungsaufbau über TUC_KON_050 {ctId=CtID; role=„User} auszulösen.

    <=

    TIP1-A_4553

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu jedem CT-Object-Eintrag in CTM_CT_LIST die Werte gemäß Tabelle TAB_KON_529 einsehen zu können:
    Zu jedem Eintrag MUSS der Administrator TUC_KON_055 „Befülle CT-Object“ auslösen können.

    Tabelle 57: TAB_KON_529 Anzeigewerte zu einem Kartenterminalobjekt

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    Geräte
    kenndaten



    CT.CTID
    Identifier
    Eindeutige, statische Identifikation des Kartenterminals
    CT.IS_PHYSICAL
    Ja/Nein
    Kennzeichnung, ob es sich um ein logisches oder physisches Kartenterminal handelt
    (siehe auch TAB_KON_522 Parameterübersicht des Kartenterminaldienstes)
    CT.MAC_ADRESS
    MAC-Adresse
    die MAC-Adresse des Kartenterminals
    CT.HOSTNAME
    String
    SICCT-Terminalname des Kartenterminals, auch als FriendlyName bezeichnet
    CT.IP_ADRESS
    IP-Adresse
    die IP-Adresse des Kartenterminals
    CT.TCP_PORT
    Portnummer
    der TCP-Port des SICCT-Kommandointerpreters des Kartenterminals
    CT.SLOTCOUNT
    Nummer
    Anzahl der Slots des Kartenterminals
    CT.SLOTS_USED
    Liste
    Liste der mit Karten belegten Slots
    CT.PRODUCT
    INFORMATION

    Inhalt Product
    Information.xsd

    die Herstellerinformationen zum Kartenterminal gemäß [gemSpec_OM]
    CT.EHEALTH_
    INTERFACE_
    VERSION

    Version
    Die EHEALTH-Interface-Version des Kartenterminals, die mittels des SICCT-Kommandos GET STATUS aus dem Element VER des Discretionary Data Objects ermittelt wurde
    CT.VALID_
    VERSION

    Boolean
    True, wenn die Version des Kartenterminals (CT.EHEALTH_INTERFACE_VERSION) durch den Konnektor unterstützt wird, d.h. zu den in CTM_SUPPORTED_KT_VERSIONS passt
    Pairingdaten


    CT.SMKT_AUT
    X.509-Cert
    C.SMKT.AUT-Zertifikat des Kartenterminals, gespeichert im Rahmen des Pairings
    Verbindungs
    daten



    CT.
    CORRELATION

    bekannt
    zugewiesen
    gepairt
    aktiv
    aktualisierend

    Der Korrelationsstatus zum Konnektor:
    • bekannt (über Service Announcement/Service Discovery gelernte Kartenterminals),
    • zugewiesen (durch den Administrator aus dem Bereich der bekannten Kartenterminals oder manuell konfigurierte Kartenterminals),
    • gepairt (Pairing erfolgreich aber noch nicht zum Verbindungsaufbau freigegeben)
    • aktiv (durch Administrator zum Verbindungsaufbau freigegeben),
    • aktualisierend (ein laufender Updatevorgang, ausgelöst durch den Konnektor; Der Zustand tritt ein, wenn der Kartenterminaldienst das Event „KSR/UPDATE/START" fängt und endet mit dem Event „KSR/UPDATE/END"),
    CT.CONNECTED
    Ja/Nein
    Der Verfügbarkeitsstatus des Kartenterminals (Ja = nach Aufbau der TLS-Verbindung und erfolgter zweiter Authentifizierung)
    CT.ACTIVEROLE
    User/Admin
    Benutzerrolle, die für die aktuelle Session verwendet wird
    KT-Admin-Credentials


    CT.ADMIN_
    USERNAME

    String
    Username des Administrators am KT

    <=

    TIP1-A_4554

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu jedem CT-Object-Eintrag in CTM_CT_LIST die Werte gemäß Tabelle TAB_KON_530 ändern zu können:
    Zur Überprüfung der veränderten Parameter auf Korrektheit MUSS nach Änderung von CT.IP_ADRESS, TCP_PORT oder HOSTNAME TUC_KON_054 mit Mode= ManuallyModified und allen vorhandenen CT-Parametern aufgerufen werden. Endet der Aufruf von TUC_KON_054 mit einem Fehler, MUSS der Konnektor die geänderten Konfigurationswerte auf ihren Ausgangswert zurücksetzen.

    Tabelle 58: TAB_KON_530 Konfigurationswerte eines Kartenterminalobjekts

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    CT.IP_ADRESS
    IP-Adresse
    Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja die IPv4-Adresse des Kartenterminals eingeben können.
    CT.TCP_PORT
    Portnummer
    Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja den TCP-Port des SICCT-Kommandointerpreters des Kartenterminals eingeben können.
    CT.HOSTNAME
    String
    Der Administrator MUSS den SICCT-Terminalnamen (Hostname) - auch als FriendlyName bezeichnet - des Kartenterminals eingeben können.
    CT.ADMIN_USERNAME
    String
    Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja den Username des KT-Administrators des Kartenterminals eingeben können.
    CT.ADMIN_PASSWORD
    String
    Der Administrator MUSS für KTs mit CT.IS_PHYSICAL=Ja das Password des KT-Administrators des Kartenterminals eingeben können.

    <=

    TIP1-A_6477

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen, ein Service Discovery entsprechend [SICCT] auszulösen, um neue Kartenterminals hinzuzufügen.

    <=

    TIP1-A_4555

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen für neue Kartenterminals CT-Objects manuell in CTM_CT_LIST aufzunehmen.
    Hierzu MUSS der Administrator für das neue Kartenterminal folgende Werte eingeben können:

    Bestätigt der Administrator seine Eingaben, MUSS TUC_KON_054 mit Mode=ManuallyAdded und allen eingegebenen Parametern aufgerufen werden.
    <=

    Als Sicherung gegen den unbemerkten Austausch von Kartenterminals oder deren Identitäten wird das gSMC-KT über den Konnektor logisch an das eHealth-Kartenterminal gebunden. Dieser Vorgang wird als Pairing von Kartenterminal und gSMC-KT bezeichnet und ist ausführlich in [gemSpec_KT] beschrieben.

    TIP1-A_4556

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen alle Kartenterminals mit CT.CORRELATION = „zugewiesen“ in einer Liste einzusehen und für einen ausgewählten Eintrag mit CT.VALID_VERSION=True TUC_KON_053 auslösen zu können.

    <=

    TIP1-A_4557

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen zu einem Kartenterminal aus CTM_CT_LIST für KTs mit CT.IS_PHYSICAL=Ja den Wert für CT.CORRELATION nach folgenden Mustern zu ändern:

    <=

    TIP1-A_5698

    Die Managementschnittstelle MUSS einem Administrator die Möglichkeit bieten, Kartenterminals aus der Liste der Kartenterminals (CTM_CT_LIST) zu entfernen.
    <=

    4.1.4.6.3 Import der Kartenterminal-Informationen

    Im Rahmen des Konnektormanagements müssen die Konfigurationsdaten des Konnektors ex- und importiert werden können (siehe Kapitel 4.3.3). Eine Sonderstellung nimmt dabei der Import von Kartenterminalinformationen ein, da hier im Rahmen des Imports folgende Interaktion mit dem Administrator erforderlich ist:

    TIP1-A_5011

    Der Konnektor MUSS vor der endgültigen Aktivierung der importierten Kartenterminalkonfiguration folgende zusätzliche Schritte ausführen:

    1. Die Liste der zu importierenden Kartenterminals MUSS dem Administrator angezeigt werden. Er MUSS die Möglichkeit erhalten, einzelne Kartenterminals aus dieser Liste zu löschen.
    2. Erst nach Bestätigung durch den Administrator werden die Kartenterminalinformationen in die Kartenterminalverwaltung übernommen.
    3. Sofern die Kartenterminal-Konfiguration in einen Konnektor mit neuer Identität importiert werden soll (neuer Konnektor oder neuer privater Schlüssel und neues Zertifikat C.SAK.AUT auf der gSMC-K), muss die neue Identität des Konnektors allen importierten Kartenterminals bekannt gemacht werden (Wartungs-Pairing, siehe auch [gemSpec_KT#2.5.2.4]).
      1. Dazu baut der Konnektor unter der Nutzung von C.SAK.AUT eine temporäre TLS-Verbindung auf und sendet das eHealth-Kartenterminal-Kommando EHEALTH TERMINAL AUTHENTICATE in der Variante „ADD” an jedes in der Liste aufgeführte Kartenterminal. Mit dem Kommando und P2=03 holt sich der Konnektor eine Challenge.
      2. Der eigentliche Austausch bzw. die Aufnahme des neuen Zertifikates erfolgt im KT erst, nachdem diese Challenge mit dem Kommando EHEALTH TERMINAL AUTHENTICATE im Modus P2=04 vom Konnektor korrekt beantwortet wurde. Dieses Kommando sowie die Erzeugung der Challenge-Antwort wird in [gemSpec_KT#3.7.2.4] und [gemSpec_KT#3.7.2] beschrieben.
      3. Nach erfolgreicher Abarbeitung des Kommandos wird der Eintrag in die interne Liste der gepairten Kartenterminals übernommen und die temporäre Verbindung zum Kartenterminal abgebaut. Kann ein Kartenterminal nicht erreicht werden, so MUSS die Befehlskette nachgeholt werden, sobald das Kartenterminal vom Konnektor wieder als verfügbar erkannt wird.
    4. Zur abschließenden Kontrolle und zur weiteren fachlichen Nutzung baut der Konnektor zu jedem der neu konfigurierten und aktiv gesetzten Kartenterminals via TUC_KON_050 eine Verbindung auf.
    <=

    4.1.5 Kartendienst

    Innerhalb des Kartendienstes werden folgende Präfixe für Bezeichner verwendet:

    Der Konnektor verwaltet eine Liste aller Karten (CM_CARD_LIST), die in die vom Konnektor verwalteten Kartenterminals gesteckt sind (CTM_CT_LIST). Alle Ereignisse und Operationen, die sich auf Karten beziehen, werden durch diesen Basisdienst gekapselt.

    Für jede gesteckte Karte vergibt er einen eindeutigen Identifikator (im weiteren Text CardHandle bezeichnet), mit dem diese Karte adressiert werden kann, um zu diesen oder mit diesen Karten Operationen auszuführen. Dieses Handle ist gültig bis zum Entfernen der Karte aus dem Kartenterminal.

    Um die in [gemSpec_Perf] geforderten Zeiten für kartenbezogene Operationen erreichen zu können, kann es erforderlich sein, dass der Konnektor möglichst viele Informationen der Karten cached. Hierzu gehören Steuerdaten wie Extended Length, Version etc. aber auch Zertifikate der Karte (X.509 und CVC). Da es sich bei Caching um einen internen Mechanismus handelt, der sich nicht auf das funktionale Außenverhalten von TUCs oder Operationen auswirkt, wird das Caching nicht weiter beschrieben oder explizit gefordert. Es kann aber Anforderungen aus Sicherheitssicht bezüglich des Cachings geben (insbesondere hinsichtlich der erlaubten Caching-Dauer). Die Einhaltung dieser Vorgaben wird im Rahmen der CC-Evaluierung geprüft werden.

    Der Kartendienst verwaltet mindestens die in der informativen Tabelle TAB_KON_531 ausgewiesenen Parameter, weitere herstellerspezifische Parameter sind möglich. Die normative Festlegung wann welche Parameter wie belegt werden, erfolgt in den folgenden Abschnitten und Unterkapiteln.

    Tabelle 59: TAB_KON_531 Parameterübersicht des Kartendienstes

    ReferenzID
    Belegung
    Zustandswerte
    CM_CARD_LIST
    Liste von Card-Objekten
    Eine Liste von Repräsentanzen (CardObjects) der dem Konnektor bekannten Karten.
    Die Attribute der Card-Objekte sind im Folgenden gelistet.
    CARD.CARDHANDLE

    vom Konnektor vergebenen eindeutigen Identifikator (Handle).
    CARD.CTID

    Kartenterminal, in dem die Karte steckt
    CARD.SLOTNO

    Slot, in dem die Karte steckt
    CARD.ICCSN

    ICCSN der Karte (sofern auslesbar),
    CARD.TYPE

    Typ der Karte gemäß Tabelle TAB_KON_500 Wertetabelle Kartentypen
    CARD.CARDVERSION

    die Versionsinformationen zum Produkttyp der Karte und den gespeicherten Datenstrukturen gemäß [gemSpec_Karten_Fach_TIP].
    CARD.CARDVERSION.
    COSVERSION

    Produkttypversion des COS
    CARD.CARDVERSION.
    OBJECTSYSTEMVERSION

    Produkttypversion des Objektsystems
    CARD.CARDVERSION.
    CARDPTPERSVERSION

    Produkttypversion der Karte bei Personalisierung
    CARD.CARDVERSION.
    DATASTRUCTUREVERSION

    Version der Speicherstrukturen (aus EF.Version)
    CARD.CARDVERSION.
    LOGGINGVERSION

    Version der Befüllvorschrift für EF.Logging
    CARD.CARDVERSION.
    ATRVERSION

    Version der Befüllvorschrift für EF.ATR
    CARD.CARDVERSION.
    GDOVERSION

    Version der Befüllvorschrift für EF.GDO
    CARD.CARDVERSION.
    KEYINFOVERSION

    Version der Befüllvorschrift für KeyInfo
    CARD.INSERTTIME
    Timestamp
    Zeitpunkt, an dem die Karte gesteckt wurde
    CARD.CARDHOLDERNAME
    String
    Name des Karteninhabers bzw. der Institution/Organisation (subject.commonName)
    CARD.KVNR
    String
    Versicherten-ID (unveränderbarer Teil der KVNR)
    CARD.
    CERTEXPIRATIONDATE

    Ablaufdatum des AUT-Zertifikats der Karte
    CARD.CARDSESSION_
    LIST
    Liste von CardSession-Objekten
    Eine Liste von Repräsentanzen (CardSession-Objects) der pro Karte vorhandenen Kartensitzungen.
    Die Attribute der CardSession-Objekte sind im Folgenden gelistet.
    Das Tripel aus MandantID, CSID und UserID bildet den Kontext ab, in welchem diese Kartensitzung initiiert wurde.
    CARDSESSION.
    AUTHSTATE
    Liste von Einträgen aus a)C2C:KeyRef, Role
    oder
    b) CHV: PINRef
    Liste von erreichten Sicherheitszuständen.
    Jeder einzelne Sicherheitszustand kann entweder über C2C gegen KeyRef (mit einer bestimmten Rolle gemäß [gemSpec_PKI_TI#Tab_PKI_918]) oder Card Holder Verification (CHV) gegen eine referenzierte PIN erreicht worden sein.
    Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.
    CARDSESSION.
    MANDANTID

    Mandant-ID
    CARDSESSION.CSID

    Clientsystem-ID
    CARDSESSION.USERID

    Nutzer-ID
    CARDSESSION.AUTHBY
    Referenz auf CardSession
    Kartensitzung, über die diese Karte freigeschaltet wurde (nur für eGK belegt)
    CARDSESSION.
    SIGNMODE

    „PIN“ oder
    „Comfort“

    Signaturmodus
    „PIN“: Komfortsignaturmodus ist für die CardSession ausgeschaltet
    "Comfort“: Komfortsignaturmodus ist für die CardSession eingeschaltet
    Default-Wert=“PIN“
    Nur relevant für den HBA
    Eine HBA-CardSession mit eingeschaltetem Komfortsignaturmodus wird im Folgenden als Komfortsignatursession bezeichnet.

    4.1.5.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4988-02

    Der Konnektor MUSS für eGK, HBA, SMC-B, gSMC-KT und gSMC-K Karten der Generation 2 unterstützen. Karten der Generation 2 sind alle Karten, deren Version des dem aktiven Objektsystem zugrundeliegenden Produkttyps (Tag ‘C1‘ in EF.Version2) den Wert 4.x.y hat, wobei x,y in {0, …, 255}.
    Der Konnektor DARF eGKs der Generation < 2 (also 1 und 1+) NICHT unterstützen. eGKs der Generation < 2 werden im Konnektor als CARD.TYPE = UNKNOWN geführt.
    Bei Karten der Generation 2

    <=

    Es kann notwendig sein, Karten der Generation 2 (G2) näher zu bezeichnen. In diesem Fall wird in G2.0- und G2.1-Karten unterschieden. Wird von Karten der Generation 2 gesprochen, so gilt die Festlegung für G2.x (G2.0, G2.1 und höher) des betrachteten Kartentyps.

    TIP1-A_4558

    Sofern der Konnektor Daten gesteckter Karten cached, so DÜRFEN diese Daten von HBAx und SM-B NICHT länger als 24 Stunden gecached werden.

    Der Konnektor DARF Daten der eGK NICHT über den Steckzyklus der Karte hinaus cachen.
    Ausnahme: Eine Cachingdauer über den Steckzyklus der eGK hinaus wird von einer Fachanwendung gefordert und durch die Fachmodulspezifikation dieser Fachanwendung definiert.

    <=

    TIP1-A_6031

    Der Konnektor DARF NICHT selbsttätig die SM-B und deren Sicherheitszustände zurücksetzen, auch nicht, wenn die Daten der SM-B nach Ablauf der 24-Stunden-Frist neu in den Cache eingelesen werden.

    <=

    TIP1-A_4559

    Der Konnektor DARF NICHT auf das DF.KT einer gSMC-KT zugreifen.

    <=

    TIP1-A_4560

    Der Konnektor MUSS alle Zugriffe auf Karten aus CM_CARD_LIST, die den Sicherheitszustand der Karte erhöhen können oder einen erhöhten Sicherheitszustand der Karte voraussetzen, im Kontext einer Kartensitzung zu dieser Karte durchführen (CARD.CARDSESSION). Ausgenommen hiervon ist der Zugriff durch das CMS (bzw. VSDD) auf die eGK.

    Der Konnektor MUSS sicherstellen, dass in einer Kartensitzung nur dann auf einen erhöhten Sicherheitszustand einer Karte zugegriffen werden kann, wenn die zur Erreichung dieses Sicherheitszustandes erforderlichen Authentisierungen (PIN-Verifikation, C2C-Rollen-Authentisierung etc.) in dieser verwendeten Kartensitzung erfolgreich durchgeführt wurden.

    Der Konnektor MUSS Authentisierungen in einer Kartensitzung so durchführen, dass in anderen Kartensitzungen vorhandene Sicherheitszustände nicht beeinflusst werden. (Eine falsche PIN-Eingabe in einer Kartensitzung darf den erhöhten Sicherheitszustand einer anderen Sitzung nicht zurücksetzen etc.).

    Der Konnektor SOLL die Verwaltung der Sicherheitsstatus der Kartensitzungen so über die Nutzung logischer Kartenkanäle umsetzen, dass PIN-Verifikationen, die für die Dauer der Kartensitzung Gültigkeit haben, nicht unnötig wiederholt werden müssen.

    <=

    Für die TUCs zur PIN-Eingabe, Änderung und Entsperrung sind Festlegungen hinsichtlich der auf dem Kartenterminal anzuzeigenden Meldungen erforderlich. Die folgende Tabelle definiert diese Terminalanzeigen gemäß [SICCT#5.5.10.19].

    TIP1-A_4561-02

    Der Konnektor MUSS im Rahmen des interaktiven PIN-Handlings die folgenden Displaymessages für die Anzeige im Kartenterminal verwenden:

    Tabelle 60: TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal

    Karte/
    Kontext

    PIN-Referenz
    I/O
    Terminal-Anzeige
    ANW
    (max.Anz. Zeichen)
    eGK
    /PIN-Eingabe für Vertreter-PIN
    PIN.AMTS_REP
    I
    Vertreter-PIN•0x0Bfür•0x0BANW
    0x0FVertr-PIN:
    22
    eGK
    /PIN-Eingabe für Vertreter-PIN ändern
    PIN.AMTS_REP
    I
    Vertreter-PIN•0x0Bändern
    0x0FPIN.eGK:
    eGK
    /PIN-Eingabe für Vertreter-PIN entsperren
    PIN.AMTS_REP
    I
    Vertreter-PIN•0x0entsperren
    0x0FPIN.eGK:
    eGK
    /PIN-Eingabe für PIN-Schutz einschalten
    MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS,
    MRPIN.GDD
    I
    PIN-Schutz•0x0BANW•0x0Beinschalten
    0x0FPIN.eGK:
    16
    eGK
    /PIN-Eingabe für PIN-Schutz abschalten
    MRPIN.NFD, MRPIN.DPE, MRPIN.AMTS,
    MRPIN.GDD
    I
    PIN-Schutz•0x0BANW•0x0Babschalten
    0x0FPIN.eGK:

    16
    eGK
    /Sonstige

    ALLE (außer PIN.AMTS_REP)

    I
    PIN•0x0Bfür•0x0BANW
    0x0FPIN.eGK:
    32
    HBAx
    PIN.CH
    I
    Eingabe•0x0BFreigabe-PIN•0x0BHBA
    0x0FPIN.HBA:
    PIN.QES
    (Signatur auslösen)

    I
    #UVW-XYZ0x0BEingabe•0x0BSignatur- PIN•0x0BHBA
    0x0FPIN.QES:
    HBA PIN.QES (Komfortsignatur aktivieren) I Komfortsignatur•0x0Baktivieren•0x0BHBA
     0x0FPIN.QES:
    SMC-B

    PIN.SMC
    I
    Eingabe•0x0BPIN•SMC-B•0x0BSLOT:X
    0x0FPIN.SMC:
    ANDERE
    BELIEBIG
    I
            Herstellerspezifisch
    Erfolgreiche PIN-Eingabe
    ALLE
    O
    PIN•0x0Berfolgreich•0x0Bverifiziert!
    Fehlerhafte PIN-Eingabe
    ALLE
    O
    PIN•0x0Bfalsch•0x0Boder•0x0Bgesperrt!
    PUK-Eingabe
    eGK
    PUK.CH
    I
    Eingabe•0x0BVersicherten-0x0BPUK
    0x0FPUK.eGK:

    HBAx
    PUK.CH
    I
    Eingabe•0x0BFreigabe-PUK•0x0BHBA
    0x0FPUK.HBA:

    HBAx
    PUK.QES
    I
    Eingabe•0x0BSignatur-PUK•0x0BHBA
    0x0FPUK.QES:

    SMC-B
    PUK.SMC
    I
    Eingabe•0x0BPUK•SMC-B•0x0BSLOT:X
    0x0FPUK.SMC:
    Erfolgreiche PUK-Eingabe
    ALLE
    O
    PIN•0x0Berfolgreich•0x0Bentsperrt!
    Fehlerhafte PUK-Eingabe
    ALLE
    O
    PUK•0x0Bfalsch•0x0Boder•0x0Bgesperrt!
    Eingabe einer neuen PIN
    eGK
    ALLE (außer PIN.AMTS_REP)
    I
    Eingabe•
    0x0Bneue•0x0BVersicherten-0x0BPIN•
    0x0B(6-8•Ziffern)
    0x0FPIN.eGK:

    eGK
    PIN.AMTS_REP
    I
    Eingabe•
    0x0Bneue•0x0BVertreter-PIN•
    0x0B(6-8•Ziffern)
    0x0FVertr-PIN:

    HBAx
    PIN.CH
    I
    Eingabe•0x0Bneue•0x0BFreigabe-PIN•0x0BHBA•0x0B(6-8•Ziffern)
    0x0FPIN.HBA:

    HBAx
    PIN.QES
    I
    Eingabe•
    0x0Bneue•0x0BSignatur-PIN•0x0BHBA•0x0B(6-8•Ziffern)
    0x0FPIN.QES:

    SMC-B
    PIN.SMC
    I
    Eingabe•0x0Bneue•0x0BPIN•SMC-B•
    0x0BSLOT:X0x0B(6-8•Ziffern)
    0x0FPIN.SMC:
    Eingabe einer Transport-PIN
    eGK
    PIN.CH
    I
    Eingabe•0x0BTransport-0x0BVersicherten-0x0BPIN
    0x0FT-PIN.eGK:
    HBAx
    PIN.CH
    I
    Eingabe•0x0BTransport-0x0BPIN•0x0BHBA
    0x0FT-PIN.HBA:
    HBAx
    PIN.QES
    I
    Eingabe•0x0BTransport-0x0BPIN•0x0BHBA
    0x0FT-PIN.QES:
    SMC-B
    PIN.SMC
    I
    Eingabe•0x0BTransport-0x0BPIN•SMC-B•0x0BSLOT:X
    0x0FT-PIN.SMC:
    Wieder-holung einer neuen PIN
    eGK
    PIN.CH
    I
    Eingabe•0x0BVersicherten-0x0BPIN•0x0B
    wiederholen!
    0x0FPIN.eGK:
    eGK
    PIN.AMTS_REP
    I
    Eingabe•
    0x0Bneue•0x0BVertreter-PIN•
    0x0B wiederholen!
    0x0FVertr-PIN:
    HBAx
    PIN.CH
    I
    Eingabe•0x0Bfür•HBA•0x0Bwiederholen!
    0x0FPIN.HBA:
    HBAx
    PIN.QES
    I
    Eingabe•0x0Bfür•HBA•0x0Bwiederholen!
    0x0FPIN.QES:
    SMC-B
    PIN.SMC
    I
    Eingabe•0x0BPIN.SMC•0x0BSLOT:X 0x0Bwiederholen!
    0x0FPIN.SMC:
    Ungleichheit bei der Wieder-holung der Eingabe der neuen PIN
    ALLE
    O
    PINs•0x0B nicht•0x0Bidentisch!•0x0BAbbruch!
    Erfolgreiche PIN-Änderung
    ALLE
    O
    PIN•0x0Berfolgreich•0x0Bgeändert!
    Anzeigen am lokalen Terminal beim Remote-PIN-Verfahren für das Ergebnis der Verschlüsselung durch die gSMC-KT
    Erfolgreiche Verschlüsselung
    ALLE
    O
    Eingabe•0x0Bwird•0x0Bbearbeitet.
    Fehler bei der Verschlüsselung
    ALLE
    O
    Eingabe•0x0Bfehlgeschlagen.

    <=

    Hinweise zu den Terminalanzeigen bei PIN-Eingaben und zu obiger Tabelle:

    In den Technischen Use Cases TUC_KON_012 „PIN verifizieren“, TUC_KON_019 „PIN ändern“, TUC_KON_021 „PIN entsperren“ wird das Remote-PIN-Verfahren verwendet, sofern die Zielkarte in einem als für den Arbeitsplatz entfernt definiertem Kartenterminal steckt (siehe Kap. 4.1.1.1, Relation [7]). In diesem Fall erfolgt die Nutzerinteraktion am Remote-PIN-KT von workplaceId (PinInputKT). Dabei wendet der Konnektor das folgende Verfahren an:

    TIP1-A_5012

    Der Konnektor MUSS das Remote-PIN Verfahren im Sinne der BSI TR-03114 unterstützen. Abweichend von der TR-03114 MUSS statt der SMC-A eine gSMC-KT verwendet werden.
    Der Konnektor MUSS für die PIN-Objekte: HBA.PIN.CH, HBA.PUK.CH, HBA.PIN.QES, HBA.PUK.QES, SM-B.PIN.SMC und SM-B.PUK.SMC das Remote-PIN Verfahren unterstützen. Für alle anderen Karten und PIN-Objekte DARF das Verfahren NICHT verwendet werden.
    Für die Interaktion mit dem Anwender MÜSSEN die Display Messages entsprechend TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal verwendet werden.
    Der Ablauf für eine PIN-Operation gegen eine Zielkarte MUSS in diesen logischen Schritten erfolgen:

    1.      Aufruf TUC_KON_005 „Card-to-Card authentisieren“ mit eigens für diesen Zweck erzeugten Cardsession sowohl für die „Sendekarte“ im PinInputKT (gSMC-KT) sowie der Zielkarte. AuthMode ist „gegenseitig+TC“
    2.      Der Benutzer wird mit dem SICCT-Kommando PERFORM VERIFICATION bzw. MODIFY VERIFICATION DATA zur Eingabe der PIN am PinInputKT aufgefordert. Als Display Messages für die erfolgreiche Bearbeitung bzw. Fehler in der Bearbeitung dieser Kommandos müssen die Texte mitgesendet werden, die in TAB_KON_090 für die Ergebnisse der Verschlüsselung durch die gSMC-KT festgelegt sind.
    3.      Im PinInputKT verschlüsselt die gSMC-KT die eingegebene PIN mit dem zuvor erzeugten Sessionkey.
    4.      Die verschlüsselte PIN wird in das zur intendierten PIN-Operation passende Kommando eingebettet (PIN verifizieren, ändern oder entsperren - wird durch den eigentlichen PIN-TUC festgelegt) und das Kommando vom Konnektor an die Zielkarte zur Entschlüsselung und Verifikation übergeben. Dabei MUSS die Übertragung im gleichen Logischen Kanal wie die SM Vereinbarung erfolgen.
    5.      Der Konnektor zeigt das Resultat der Zielkarte mittels SICCT OUTPUT am lokalen Kartenterminal an. Er verwendet dabei den in TAB_KON_090 für die aktuelle PIN-Operation spezifizierten Ausgabetexte.
    6.      Das Result der Zielkarte wird an den Aufrufer zurückgegeben
    Fehlermeldung: Ein Fehler in der Verarbeitung führt zum Abbruch mit Fehlercode 4053 „Remote-PIN nicht möglich“ (Security, Error).
    <=

    Hinweis: Derzeit schlägt die Freischaltung der SMC-B durch Card-2-Card-Authentisierung ohne Fehlermeldung fehl. Der Sicherheitszustand der SMC-B wird nicht verändert. Diese Einschränkung betrifft TUC_KON_005 „Card-to-Card authentisieren“ (TAB_KON_096).

    4.1.5.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_4562

    Empfängt der Kartendienst das Ereignis „CT/SLOT_FREE“, so MUSS der Konnektor:


    <=

    TIP1-A_4563

    Empfängt der Kartendienst das Ereignis „CT/SLOT_IN_USE“, so MUSS der Konnektor für die Karte, die über die im Ereignis gemeldeten Parameter CtID und SlotNo adressiert ist, über TUC_KON_001 ein neues CardObject in CM_CARD_LIST anlegen.

    <=

    4.1.5.3 Interne TUCs, nicht durch Fachmodule nutzbar
    4.1.5.3.1 TUC_KON_001 „Karte öffnen“

    TIP1-A_4565

    Der Konnektor MUSS den technischen Use Case „Karte öffnen“ gemäß TUC_KON_001 umsetzen.

    Tabelle 61: TAB_KON_734 – TUC_KON_001 „Karte öffnen“

    Element
    Beschreibung
    Name
    TUC_KON_001 „Karte öffnen“
    Beschreibung
    Der TUC initialisiert ein Card-Object basierend auf einer physikalischen Karte und fügt es CM_CARD_LIST zu. Die Karte kann erst im Anschluss unter Verwendung des erzeugten CardHandles verwendet werden.
    Auslöser
    Der Kartenterminaldienst meldet das Belegen eines KT-Slots
    Vorbedingungen
    •      In ctId/slotId steckt eine Karte
    Eingangsdaten
    •      ctId
      (Kartenterminalidentifikator)
    •      slotId
      (Nummer des Kartenslots)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
    1. Prüfe, ob unter ctId und slotId ein Eintrag in CM_CARD_LIST
        vorhanden ist. Wenn bereits ein Eintrag vorhanden ist, lösche diesen.
    2. Erzeuge neuen Card-Object-Eintrag in CM_CARD_LIST und
    a)      Generiere CARD.CARDHANDLE. mit folgenden Anforderungen:

                -               Das CardHandle MUSS innerhalb CM_CARD_LIST
                     eindeutig sein.
                -               Ein ungültig gewordenes CardHandle DARF innerhalb
                     von 48h NICHT als neues CardHandle vergeben werden.
    b)      Befülle CARD.CTID und CARD.SLOTNO mit den Eingangsdaten
    c)      Ermittle und befülle (soweit durch Karte unterstützt) die folgenden
         Daten:
                -               CARD.ICCSN
                -               CARD.TYPE (mögliche Werte siehe Tabelle
                     TAB_KON_500 Wertetabelle Kartentypen)
                -               CARD.CARDVERSION
                -               CARD.INSERTTIME (=aktuelle Systemzeit)
                -               CARD.CARDHOLDERNAME (aus X.509-AUT-
                      Zertifikat)
                -               CARD.KVNR (nur für eGK, aus C.CH.AUT:
                      unveränderbarer Teil der KVNR)
                -               CARD.CERTEXPIRATIONDATE (=validity aus X.509-
                      AUT-Zertifikat)

    X.509-AUT-Zertifikat bezeichnet für eGK das C.CH.AUT-Zertifikat, für HBAx das C.HP.AUT-Zertifikat und für SMC-B das C.HCI.AUT-Zertifikat.

    3. Rufe TUC_KON_256{
               topic = „CARD/INSERTED“;
               eventType = Op;
               severity = Info;
               parameters = <Params>}
         mit <Params> belegt aus dem CARD-Object:
    „CardHandle=$, CardType=$, CardVersion=$, ICCSN=$,CtID=$,
    SlotID=$, InsertTime=$, CardHolderName=$, KVNR=$,
    CertExpirationDate=$“

    In CardVersion sind die Werte
       - COSVERSION und
       - OBJECTSYSTEMVERSION
    aus CARD.CARDVERSION einzutragen. Für eGK G1+ ist zusätzlich die
       - DATASTRUCTUREVERSION
    aus CARD.CARDVERSION einzutragen. CardVersion kann weitere Werte
    aus CARD.CARDVERSION enthalten.

    Varianten/
    Alternativen
    Im Falle der KVK gibt es kein EF.ATR, EF.GDO und EF.DIR. Es wird daher
      lediglich der ATR ausgewertet, den das Kartenterminal beim Stecken der
      Karte liefert.

    Fehlerfälle
    (-> 2c) Karte/Kartenterminal antwortet mit einer spezifischen Fehlermeldung, Fehlercode <gemäß [gemSpec_COS]/[SICCT]>
    Auch im Fehlerfall wird Schritt 3 durchlaufen. Wenn nicht alle zu einem Kartentyp notwendigen Daten von der Karte gelesen werden konnten, dann wird Schritt 3 mit CardType=UNKNOWN ausgeführt.
    Auch im Fehlerfall wird Schritt 3 durchlaufen. Wenn nicht alle zu einem Kartentyp notwendigen Daten von der Karte gelesen werden konnten, dann wird Schritt 3 mit CardType=UNKNOWN ausgeführt.
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    <=

    4.1.5.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.5.4.1 TUC_KON_026 „Liefere CardSession“

    TIP1-A_4566

    Der Konnektor MUSS den technischen Use Case „Liefere CardSession“ gemäß TUC_KON_26 umsetzen.

    Tabelle 62: TAB_KON_735 - TUC_KON_026

    Element
    Beschreibung
    Name
    TUC_KON_026 „Liefere CardSession“
    Beschreibung
    Dieser Use Case gibt auf Grund der übergebenen Parameter die zugehörige CardSession zurück. Ist für die Parameterkombination noch keine CardSession vorhanden, wird eine neue erzeugt und im zugehörigen Card-Object hinterlegt.
    Auslöser
    •     Indirekter Aufruf über durch Clientsysteme ausgeführte Operationen.
    •     Aufruf durch Fachmodul
    Vorbedingungen
    Keine
    Eingangsdaten
    • mandantId
    • clientSystemId
    • cardHandle
    • userId - optional/verpflichtend, wenn cardType = HBAx
    Komponenten
    Konnektor
    Ausgangsdaten
    • cardSession
    Standardablauf
    1.    Ermittle Card in CM_CARD_LIST über cardHandle
    2.    Prüfe dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3.    Ermittle cardSession in Card.CARDSESSION_LIST über mandantId, clientSystemId und userId
    Varianten/
    Alternativen
    (3) Wenn keine CardSession für diese Parameter vorhanden:
     1.                    erzeuge neue CardSession in Card.
            CARDSESSION_LIST
     2.                    Befülle CARDSESSION.MANDANTID, .CSID und
            .USERID mit Übergabeparametern

    Fehlerfälle
    (2) Karte bereits reserviert, Fehlercode 4093
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 63: TAB_KON_824 Fehlercodes TUC_KON_026 „Liefere CardSession“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet

    <=

    Hinweis zu TAB_KON_735 - TUC_KON_026: Die WorkplaceId wird als Eingangsparameter nicht benötigt. Bereits TUC_KON_000 stellt sicher, dass eine eGK jeweils nur von einem einzigen Arbeitsplatz aus angesprochen werden kann.

    4.1.5.4.2 TUC_KON_012 „PIN verifizieren“

    TIP1-A_4567

    Der Konnektor MUSS den technischen Use Case „PIN verifizieren“ gemäß TUC_KON_012 umsetzen.

    Tabelle 64: TAB_KON_087 – TUC_KON_012 „PIN verifizieren“

    Element
    Beschreibung
    Name
    TUC_KON_012 „PIN verifizieren“
    Beschreibung
    Dieser Use Case führt die Verifikation einer PIN einer Karte durch. Dabei wird der Anwender am Display des Kartenterminals aufgefordert, die PIN einzugeben. Dies erfolgt am PIN-Pad des Kartenterminals.
    Remote-PIN-Eingabe wird dabei automatisch unterstützt.
    Auslöser
    •     Aufruf des Use Case durch Basisdienste des Konnektors
    •     Aufruf des Use Cases durch ein Fachmodul im Konnektor
    •     Aufruf der Operation VerifyPin des CardService (siehe 4.1.5.5.1) durch das Clientsystem.
    Vorbedingungen
    Karte unterstützt die übergebene pinRef
    Eingangsdaten
    • cardSession
      (Kartensitzung der Karte, deren PIN verifiziert werden soll)
    • workplaceId
    • pinRef
      (Referenz auf die zu verifizierende PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps.)
    • actionName – optional/verpflichtend, wenn cardType = eGK
      (Zeichenkette, max. 32 bzw. 22 Zeichen PIN.AMTS_REP mit dem Namen der zugreifenden Fachanwendung bzw. des zu nutzenden Datenobjekts und der Zugriffsart, die mit dieser PIN freigeschaltet werden soll,
      z. B. für MRPIN.NFD: actionName  = „Notfalldaten schreiben“;
      Positionen in der Zeichenkette, an denen ein Zeilenumbruch bei der Ausgabe am Kartenterminal erlaubt ist, werden mit `0x0B` gekennzeichnet. `0x0B` zählt bei der Länge der Zeichenkette nicht.)
    • verificationType [Mandatorisch | Sitzung]
      (Art der PIN-Verifikation:
      •          Mandatorisch: PIN wird immer verifiziert.
      •          Sitzung: PIN wird nicht erneut verifiziert, falls dies für die cardSession zuvor bereits geschehen ist und der dadurch erreichte Sicherheitszustand nicht zurückgesetzt wurde.)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    • pinResult [PinResult]
      (Ergebnis der PIN-Verifikation)
    • leftTries – optional/verpflichtend, wenn pinResult = REJECTED
      (Anzahl der verbleibenden Versuche)
    Standardablauf
    1.         Ermittle Card = CM_CARD_LIST(CardSession)
    2.         Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder
         der Aufrufer das Karten-Lock besitzt.
    3.         Wenn PinTyp(pinRef) = PIN.QES oder
         VerificationType = Mandatorisch 6.
    4.         Wenn pinRef in CARDSESSION.AUTHSTATE vorhanden:
            pinResult = OK;
    5.         Prüfe TUC_KON_022 „Liefere PIN-Status“
            a.        „VERIFYABLE“; 
            b.        „DISABLED“: pinResult = OK;
    6.         Ermittle PinInputKT: Wenn Card.ctId ein dem
         Arbeitsplatz(workplaceId) lokal zugeordnetes Kartenterminal ist
         (siehe Relation [6], Kapitel 4.1.1.1)
            a.            Setze PinInputKT = Card.CtID
            b.            sonst „lokales Kartenterminal, das für die Remote-PIN-
                   Eingabe zu verwenden ist“: PinInputKT =
                   Arbeitsplatz(workplaceId).remote-PIN-KT(mandantId)
    7.         Atomare Operation: PIN verifizieren inkl. Eventing und
         Ergebnisvermerk
         a.             Rufe TUC_KON_256 {
                   topic = „CARD/PIN/VERIFY_STARTED“;
                   eventType = Op;
                   severity =Info;
                   parameters = („CardHandle=$, CardType=$,
                             ICCSN=$, CtID=$, SlotID=$,
                             PinRef=$, PinInputCtID=$PinInputKT“,
                   doLog=false)}
         b.             Pin-Verifikation über „Perform Verification“ ([SICCT]) mit
             Display Messages gemäß Kontext in TAB_KON_090
              Terminalanzeigen beim Eingeben der PIN am Kartenterminal, bei
              eGK ersetze „ANW“ durch actionName in Display Message.
              Wenn PinInputKT=Card.CtID dann PIN Verifikation direkt an
              Card.CtID, ansonsten Remote-PIN-Eingabe gemäß (TIP1-
              A_5012)
         c.             Setze pinResult in Abhängigkeit von Ergebnis Perform
              Verification:
                    -         pinResult = OK für erfolgreiche Prüfung
                    -         pinResult = ERROR für Nutzer-Abbruch oder
                      Bearbeitungsfehler (siehe Fehlerfälle)
               -              pinResult = REJECTED für falsche PIN;
                      leftTries = x (bei Kartenantwort ´63 Cx´, x > 0)
                    -         pinResult = BLOCKED für gesperrte PIN (bei
                      Kartenantwort ´63 C0´)
         d.            Rufe TUC_KON_256 {
                  topic = „CARD/PIN/VERIFY_FINISHED“;
                  eventType = Op;
                  severity = Info;
                  parameters = („CardHandle=$, CardType=$,
                             ICCSN=$, CtID=$, SlotID=$, PinRef=$,
                             PinInputCtID=$PinInputKT, Result=$pinResult“);
                  doLog = false }
        e.             befülle CARDSESSION.AUTHSTATE mit pinRef und
              Ergebnis der PIN-Prüfung
    8.         Liefere pinResult zurück
    Varianten/
    Alternativen
    Schritt 7e: Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.
    Fehlerfälle
    Schritt 7 wird mit allen Teilschritten durchlaufen. Ein als Fehler ausgewiesener Zustand führt erst nach Schritt 7e zum Abbruch des TUCs. Fehleingaben zählen explizit nicht zu den Fehlerzuständen, sondern werden auf das Ergebnis REJECTED oder BLOCKED abgebildet.
        * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD
              Sekunden, Fehlercode 4094
      (2) Karte ist fremd reserviert, Fehlercode 4093
      (5) Rückgabewert=
              - VERIFIED, Fehlercode 4001
              - TRANSPORT_PIN oder EMPTY_PIN, Fehlercode 4065
              - BLOCKED, Fehlercode 4063
      (6b) kein Remote-PIN-KT zugeordnet, Fehlercode 4092
      (->6b) Card.TYP=eGK und Card.CtID ist nicht dem durch workplaceId
              bezeichneten Arbeitsplatz lokal zugeordnet: Fehlercode 4053
      (7) Timeout bei PIN Eingabe: Fehlercode 4043
      (7) Abbruch durch Nutzer: Fehlercode 4049
      (7) Sind das für die PIN-Eingabe benötigte Kartenterminal oder
              benötigte Teile davon (PIN Pad, Display) durch einen anderen
              zeitgleich im Konnektor ablaufenden Vorgang reserviert, so bricht
              der Use Case mit Fehler 4060 ab.
      (7) Rückgabewert=
             - transportgeschützt (Transport-PIN oder Leer-PIN), Fehlercode
             4065
      (7b) Ungültige PIN-Referenz; Fehlercode 4072
      (7b) Karte/Kartenterminal antwortet mit einer spezifischen
             Fehlermeldung, Fehlercode <gemäß [gemSpec_COS]/[SICCT]>
    Zusätzliche Fehlerfälle ergeben sich aus der Remote-PIN-Eingabe gemäß (TIP1-A_5012)
    Nichtfunktionale Anforderungen


    Zugehörige 
    Diagramme
    Abbildung PIC_KON_111 Aktivitätsdiagramm zu „PIN verifizieren“


    Abbildung 10: PIC_KON_111 Aktivitätsdiagramm zu „PIN verifizieren“

    Tabelle 65: TAB_KON_089 Fehlercodes TUC_KON_012 „PIN verifizieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4001
    Technical
    Error
    Interner Fehler
    4043
    Technical
    Warning
    Timeout bei der PIN-Eingabe
    4049
    Technical
    Error
    Abbruch durch den Benutzer
    4053
    Security
    Error
    Remote-PIN nicht möglich
    4060
    Technical
    Error
    Ressource belegt
    4063
    Security
    Error
    PIN bereits gesperrt (BLOCKED)
    4065
    Technical
    Warning
    PIN ist transportgeschützt, Änderung erforderlich
    4072
    Technical
    Error
    Ungültige PIN-Referenz PinRef
    4092
    Technical
    Error
    Remote-PIN-KT benötigt aber für diesen Arbeitsplatz nicht definiert
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten



    <=

    4.1.5.4.3 TUC_KON_019 „PIN ändern“

    TIP1-A_4568

    Der Konnektor MUSS den technischen Use Case „PIN ändern“ gemäß TUC_KON_019 umsetzen.

    Tabelle 66: TAB_KON_736 – TUC_KON_019 „PIN ändern“

    Element
    Beschreibung
    Name
    TUC_KON_019 „PIN ändern“
    Beschreibung
    Dieser Use Case führt die Änderung einer PIN einer Karte durch. Dabei wird der Anwender am Display des Kartenterminals aufgefordert, alte und neue PIN einzugeben.
    Remote-PIN-Eingabe wird dabei automatisch unterstützt.
    Auslöser
    •       Aufruf der Operation ChangePin des CardService (siehe 4.1.5.5.2) durch das Clientsystem.
    •       Aufruf durch Fachmodul
    Vorbedingungen
    Karte unterstützt die übergebene pinRef
    Eingangsdaten
    •       cardSession
    •       workplaceId
      (Arbeitsplatz-Identifikator)
    •       pinRef
      (Referenz auf die zu ändernde PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
    •       sourceCardSession – optional/verpflichtend, wenn C2C erforderlich ist
      (CardSession der Karte, die für die Card-to-Card-Authentisierung bei Änderung der PIN einer eGK der Generation 1+ verwendet werden soll.)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    •       pinResult [PinResult]
      (Ergebnis der PIN-Verifikation)
    •       leftTries – optional/verpflichtend, wenn pinStatus = REJECTED
      (verbleibende Versuche)
    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(CardSession)
    2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3. Prüfe TUC_KON_022 „Liefere PIN-Status“ {cardSession; pinRef}<>BLOCKED
    4. Wenn pinRef=PIN.AMTS_REP,  dann
      rufe TUC_KON_012 „PIN verifizieren“ {
        cardSession;
        workplaceId;
          pinRef=PIN.CH;
        actionName= „”;
        mandatorisch}
    5. Wenn Card.TYP=eGK UND Card.Version=Generation1+, dann Aufruf TUC_KON_005 „Card-to-Card authentisieren“{
           sourceCardSession;
           targetCardSession=cardSession;
           AuthMode =einseitig}.
      Falls keine sourceCardSession angegeben ist, kann die CardSession der für den Mandanten verwalteten SMC-B verwendet werden.  
    6. Ermittle PinInputKT: Wenn Card.ctId ein dem Arbeitsplatz (workplaceId) lokal zugeordnetes Kartenterminal ist (siehe Relation [6], Kapitel 4.1.1.1)
      1. Setze PinInputKT = Card.CtID
      2. sonst „lokales Kartenterminal, das für die Remote-PIN-Eingabe zu verwenden ist“: PinInputKT = Arbeitsplatz(workplaceId).remote-PIN-KT(mandantId)
    7. Atomare Operation: PIN ändern inkl. Eventing und Ergebnisvermerk
      1. Rufe TUC_KON_256 {
            topic = „CARD/PIN/CHANGE_STARTED“;
            eventType = Op;
            severity = Info;
            parameters = („CardHandle=$, CardType=$,
                        ICCSN=$, CtID=$, SlotID=$, PinRef=$,
                        PinInputCtID=$PinInputKT“);
            doLog = false }
      2. Pin-Änderung über „MODIFY VERIFICATION DATA“ ([SICCT]) mit Display Messages entsprechend TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal.     Bei Änderung der Versicherten-PIN der  eGK ist dabei der Platzhalter „ANW“ durch den String „Änderung“ zu ersetzen. Der Platzhalter "#UVW-XYZ" entfällt für die PIN.QES des HBA.
        Wenn PinInputKT=Card.CtID, dann PIN-Änderung direkt an Card.CtID, ansonsten Remote-PIN-Eingabe gemäß (TIP1-A_5012)    
        Dabei sowohl Unterstützung normaler PIN-Änderung als auch Umsetzens eines Transportschutzes (alle Varianten gemäß Kartenspec sind zu unterstützen)
      3. Setze pinResult in Abhängigkeit von Ergebnis MODIFY VERIFICATION DATA:
        -    pinResult = OK für erfolgreiche Änderung
        -    pinResult = ERROR für Nutzer-Abbruch oder
                                   Bearbeitungsfehler (siehe Fehlerfälle)
            pinResult = REJECTED für falsche PIN-Eingaben;
                                 leftTries = x
                                 (bei Kartenantwort ´63 Cx´, x > 0)
        -    pinResult = BLOCKED für gesperrte PIN (bei Kartenantwort ´63 C0´)
      4. Rufe TUC_KON_256 {
            topic = „CARD/PIN/CHANGE_FINISHED“;
            eventType = Op;
            severity = Info;
            parameters = („CardHandle=$, CardType=$,
                        ICCSN=$;CtID=$, SlotID=$, PinRef=$,
                        PinInputCtID=$PinInputKT, Result=pinStatus“);
            doLog = false}
      5. Wenn Result = REJECTED oder BLOCKED , dann entferne PinRef aus CARDSESSION.AUTHSTATE
    8. Liefere pinResult und ggf. leftTries zurück
    Varianten/
    Alternativen
    Schritt 4: Für eGK G2.0 gilt:
        Wenn pinRef=PIN.AMTS_REP, dann
           rufe TUC_KON_012 „PIN verifizieren“ {
                  cardSession;
                  workplaceId;
                  pinRef=MRPIN.AMTS;
                  actionName= „”;
                  mandatorisch}
    Schritt 7e: Für eGK G2.0 wird der Zustand der MRPINs nicht in AuthState gespeichert.
    Fehlerfälle
    Schritt 7 wird mit allen Teilschritten durchlaufen. Ein als Fehler ausgewiesener Zustand führt erst nach Schritt 7e zum Abbruch des TUCs.
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden,
       Fehlercode 4094
    (2) Karte ist fremd reserviert, Fehlercode 4093
           (3) pinStatus=BLOCKED: Fehlercode 4063
    (5) sourceCardSession benötigt aber leer, Fehlercode 4071
    (6b) kein Remote-PIN-KT zugeordnet, Fehlercode 4092
    (->6b) Card.TYP=eGK und Card.CtID ist nicht dem durch workplaceId
          bezeichneten Arbeitsplatz lokal zugeordnet: Fehlercode 4053
    (7b) neue PIN zu kurz/lang: Fehlercode 4068
    (7b) zweite neue PIN<> erste neue PIN: Fehlercode 4067
           (7b) Timeout bei PIN-Eingabe: Fehlercode 4043.
    (7b) Abbruch durch Nutzer: Fehlercode 4049.
    (7b) Ist das Kartenterminal oder Teile davon (PIN-Pad, Display) durch
          einen anderen Vorgang reserviert: Fehlercode 4060
    (7b) kein PIN-Pad am Kartenterminal verfügbar: Fehlercode 4066
    (7b) Ungültige PIN-Referenz; Fehlercode 4072
    (7b) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode
          <Kartenfehlercode gemäß [gemSpec_COS]>
    Zusätzliche Fehlerfälle ergeben sich aus der Remote-PIN-Eingabe gemäß (TIP1-A_5012)
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 67: TAB_KON_093 Fehlercodes TUC_KON_019 „PIN ändern“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4043
    Technical
    Warning
    Timeout bei der PIN-Eingabe
    4049
    Technical
    Error
    Abbruch durch den Benutzer
    4053
    Security
    Error
    Remote-PIN nicht möglich
    4060
    Technical
    Error
    Ressource belegt
    4063
    Security
    Error
    PIN bereits blockiert (BLOCKED)
    4066
    Technical
    Error
    PIN Pad nicht verfügbar
    4067
    Security
    Error
    neue PIN nicht identisch
    4068
    Security
    Error
    neue PIN zu kurz/zu lang
    4071
    Technical
    Error
    keine Karte für C2C-Auth gesetzt
    4072
    Technical
    Error
    ungültige PIN-Referenz PinRef
    4092
    Technical
    Error
    Remote-PIN-KT benötigt aber für diesen Arbeitsplatz nicht definiert
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    <=

    4.1.5.4.4 TUC_KON_021 „PIN entsperren“

    TIP1-A_4569-02

    Der Konnektor MUSS den technischen Use Case „PIN entsperren“ gemäß TUC_KON_021 umsetzen.

    Tabelle 68: TAB_KON_236 – TUC_KON_021 „PIN entsperren“

    Element
    Beschreibung
    Name
    TUC_KON_021 „PIN entsperren“
    Beschreibung

    Dieser Use Case setzt den Fehlbedienungszähler für diese PIN in der Karte auf seinen Anfangswert zurück und es wird optional eine neue PIN gesetzt.
    Remote-PIN-Eingabe wird dabei automatisch unterstützt.
    Auslöser

    • Aufruf der Operation UnblockPin des CardService (siehe 4.1.5.5.4) durch das Clientsystem.
    Vorbedingungen
    Karte unterstützt die übergebene pinRef
    Eingangsdaten

    • cardSession
      CardSession der Karte, deren PIN entsperrt werden soll)
    • workplaceId
    • pinRef
      (Referenz auf die zu entsperrende PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
    setNewPin (true/false) - Angabe, ob eine neue PIN gesetzt oder die aktuelle weiterverwendet werden soll. Default = false
    sourceCardSession - optional/wenn eGK G1+
    (CardSession der Karte, die für die Card-to-Card-Authentisierung bei Entsperrung der PIN einer eGK der Generation 1+ verwendet werden soll)

    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten

    • result [PukResult])
      (Ergebnis der PIN-Entsperrung durch PUK-Eingabe)
    • leftTries – optional/verpflichtend, wenn pukStatus = REJECTED
      (verbleibende Versuche des PUKs)
    Standardablauf

    1.       Ermittle Card = CM_CARD_LIST(Target.CardHandle)
    2.       Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3.       Wenn TUC_KON_022 „Liefere PIN-Status“ {
          cardSession;
          pinRef } <>( „BLOCKED“ oder "TRANSPORT_PIN" ) 
      dann beende TUC erfolgreich.
    4.       Wenn pinRef=PIN.AMTS_REP,  dann
      1.             setNewPin = true
      2.             rufe TUC_KON_012 „PIN verifizieren“ {
            cardSession;
            workplaceId;
              pinRef=PIN.CH;
            actionName= „”;
            mandatorisch}
    5.       Wenn Card.TYP=eGK UND Card.Version=Generation1+, dann Aufruf TUC_KON_005 „Card-to-Card authentisieren“ {
         sourceCardSession;
         targetCardSession=cardSession;
         AuthMode =einseitig }.
      Falls keine sourceCardSession angegeben ist, kann die CardSession der für den Mandanten verwalteten SMC-B verwendet werden.
    6.       Ermittle PinInputKT: Wenn Card.ctId ein dem Arbeitsplatz(workplaceId) lokal zugeordnetes Kartenterminal ist (siehe Relation [6], Kapitel 4.1.1.1)
      1.             Setze PinInputKT = Card.CtID
      2.             sonst „lokales Kartenterminal, das für die Remote-PIN-Eingabe zu verwenden ist“: PinInputKT = Arbeitsplatz(workplaceId).remote-PIN-KT(mandantId)
    7.       Atomare Operation: PIN entsperren inkl. Eventing und Ergebnisvermerk
      1.             Rufe TUC_KON_256 {
            topic = „CARD/PIN/CHANGE_STARTED“;
            eventType = Op;
            severity = Info;
            parameters = („CardHandle=$, CardType=$,
                        ICCSN=$, CtID=$; SlotID=$, PinRef=$,
                        PinInputCtID=$PinInputKT“);
            doLog=false}
      2.             PIN-Entsperrung mit Display Messages entsprechend TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal.    
        Wenn PinInputKT=Card.CtID, dann PIN-Änderung direkt an Card.CtID, ansonsten Remote-PIN-Eingabe gemäß (TIP1-A_5012)
        •     Für pinRef == PIN.QES über „PERFORM
          VERIFICATION“ [SICCT] mit dem eingebetteten Kommando Reset Retry Counter in der Variante P1=1 (keine neue PIN setzen).
        •     Für pinRef<>PIN.QES
          wenn setNewPin = false,
              dann über PERFORM VERIFICATION“ [SICCT],
          sonst über „MODIFY VERIFICATION DATA“ [SICCT].
          Das mit dem SICCT-Kommando als Command-To-Perform mitgesandte „Reset Retry Counter“ wird entsprechend dem Wert von setNewPIN parametrisiert.
      3.             Setze result in Abhängigkeit von Ergebnis Perform Verification bzw. Modify VerificationData:
        • result = OK für erfolgreiche Entsperrung
        • result = ERROR für Nutzer-Abbruch oder Bearbeitungsfehler (siehe Fehlerfälle)
        • result = REJECTED für falsche PUK;
        • result = BLOCKED für gesperrte PUK; (bei Kartenantwort ´63 C0´)
      4.             Rufe TUC_KON_256 {
          topic=„CARD/PIN/CHANGE_FINISHED“;
          eventType=Op; severity=Info;
          parameters = („CardHandle=$; CardType=$; ICCSN=$;CtID=$; SlotID=$; PinRef=$; PinInputCtID=$PinInputKT; Result=$“);
        doLog=false }
    8.       Liefere result und ggf. leftTries zurück
    Varianten/
    Alternativen

    Schritt 4: Für eGK G2.0 gilt:
        Wenn pinRef=PIN.AMTS_REP,  dann
           rufe TUC_KON_012 „PIN verifizieren“ {
                  cardSession;
                  workplaceId;
                  pinRef=MRPIN.AMTS;
                  actionName= „”;
                  mandatorisch}

    Fehlerfälle

    Schritt 7 wird mit allen Teilschritten durchlaufen. Ein als Fehler ausgewiesener Zustand führt erst nach Schritt 7d zum Abbruch des TUCs.
      * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD
             Sekunden, Fehlercode 4094
      (2) Karte wird in einer anderen Kartensitzung exklusiv
             verwendet, Fehlercode 4093
      (5) sourceCardSession benötigt aber leer, Fehlercode 4071  
      (6b) kein Remote-PIN-KT zugeordnet, Fehlercode 4092
      (6b) Card.TYP=eGK und Card.CtID ist nicht dem durch workplaceId
             bezeichneten Arbeitsplatz lokal zugeordnet: Fehlercode 4053
      (7b) blockierte PUK: Fehlercode 4064
      (7b) neue PIN zu kurz/lang: Fehlercode 4068
      (7b) zweite neue PIN<> erste neue PIN: Fehlercode 4067
      (7b) Timeout bei PIN Eingabe: Fehlercode 4043.
      (7b) Abbruch durch Nutzer: Fehlercode 4049.
      (7b) Ist das Kartenterminal oder Teile davon (PIN-Pad, Display) durch
            einen anderen Vorgang reserviert: Fehlercode 4060
      (7b) Karte/Kartenterminal antwortet mit einer spezifischen
            Fehlermeldung, Fehlercode <gemäß [gemSpec_COS]/[SICCT]>
      (7b) Ungültige PIN-Referenz; Fehlercode 4072.
    Zusätzliche Fehlerfälle ergeben sich aus der Remote-PIN-Eingabe gemäß (TIP1-A_5012)

    Nichtfunktionale Anforderungen
    Keine

    Zugehörige Diagramme
    Keine

    Tabelle 69: TAB_KON_193 Fehlercodes TUC_KON_021 „PIN entsperren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4043
    Technical
    Warning
    Timeout bei der PIN-Eingabe
    4049
    Technical
    Error
    Abbruch durch den Benutzer
    4053
    Security
    Error
    Remote-PIN nicht möglich
    4060
    Technical
    Error
    Ressource belegt
    4064
    Security
    Error
    alte PIN bereits blockiert (hier: PUK)
    4067
    Security
    Error
    neue PIN nicht identisch
    4068
    Security
    Error
    neue PIN zu kurz/zu lang
    4072 Technical Error ungültige PIN-Referenz PinRef
    4092
    Technical
    Error
    Remote-PIN-KT benötigt aber für diesen Arbeitsplatz nicht definiert
    4093
    Technical
    Error Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    <=

    4.1.5.4.5 TUC_KON_022 „Liefere PIN-Status“

    TIP1-A_4570

    Der Konnektor MUSS den technischen Use Case „Liefere PIN-Status“ gemäß TUC_KON_022 umsetzen.

    Tabelle 70 TAB_KON_532 – TUC_KON_022 „Liefere PIN-Status“

    Element
    Beschreibung
    Name
    TUC_KON_022 „Liefere PIN-Status“
    Beschreibung
    Dieser Use Case prüft den Zustand eines PIN-Objekts einer Karte im Kontext einer CardSession.
    Auslöser
    • Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors
    • Aufruf des Use Cases durch ein Fachmodul im Konnektor
    • Aufruf der Operation GetPinStatus des CardService (siehe 4.1.5.5.1) durch das Clientsystem.
    Vorbedingungen
    Karte unterstützt die übergebene pinRef
    Eingangsdaten
    • cardSession
    • pinRef
      (Pin-Referenz der angefragten PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    • pinStatus [PinStatus]
    • leftTries – optional/verpflichtend, wenn pinStatus = VERIFYABLE
      (Anzahl der verbleibenden Versuche für die Verifikation der PIN)
    Standardablauf
     1.         Ermittle Card = CM_CARD_LIST(cardSession)
     2.         Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der
           Aufrufer das Karten-Lock besitzt.
     3.         pinRef in CardSession.AUTHSTATE vorhanden:
       a) Ja:    Setze pinStatus = VERIFIED oder DISABLED (wie in
                    AUTHSTATE)
       b) Nein:Aufruf der Kartenoperation „GET PIN STATUS“, Antwort der
                    Karte wird ausgewertet:
                    a.             ´90 00´ (NoError: Verifiziert ): pinStatus =
                         VERIFYABLE  (da nicht in dieser CardSession verifiziert)
                    b.             ´62 C1´: pinStatus = TRANSPORT_PIN
                    c.             ´62 C7´: pinStatus = EMPTY_PIN (Leer-PIN)
                    d.             ´63 Cx´: pinStatus = VERIFYABLE  (mit 1<= x <= 3);
                        LeftTries=x
                    e.             ´63 C0´: pinStatus = BLOCKED; leftTries=0
                    f.              ´62 D0´: pinStatus = DISABLED (Verifikation nicht
                        erforderlich, da PIN-Schutz ausgeschaltet);
                        cardSession.AUTHSTATE aktualisieren
                    g.              Antwortet die Karte mit einer Fehlermeldung, bricht
                        der TUC ab.
    Liefere leftTries nur in den Fällen d und e zurück.
    Varianten/
    Alternativen

    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden,
           Fehlercode 4094
    (3b) pinRef nicht gefunden: Fehlercode 4072
    Zugehörige
    Diagramme
    keine

    Tabelle 71: TAB_KON_091 Fehlercodes TUC_KON_022 „Liefere PIN-Status“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4072 Technical Error ungültige PIN-Referenz PinRef
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten

    <=

    4.1.5.4.6 TUC_KON_027 „PIN-Schutz ein-/ausschalten“

    TIP1-A_5486

    Der Konnektor MUSS den technischen Use Case TUC_KON_027 „PIN-Schutz ein-/ausschalten“ umsetzen.

    Tabelle 72: TAB_KON_240 - TUC_KON_027 „PIN-Schutz ein-/ausschalten”

    Element
    Beschreibung
    Name
    TUC_KON_027 „PIN-Schutz ein-/ausschalten”
    Beschreibung

    Schaltet das Erfordernis, die PIN zu verifizieren, ein bzw. aus.
    Diese Operation wird nur unterstützt für PINs der EGK G2 gemäß [gemSpec_eGK_ObjSys]; für sie können folgende Kommandos auf das Passwortobjekt angewendet werden:
    •       DISABLE VERIFICATION REQUIREMENT
    •       ENABLE VERIFICATION REQUIREMENT
    Auslöser

    •       Aufruf durch ein Fachmodul
    •       Aufruf der Operationen EnablePin und DisablePin des CardService durch das Clientsystem.
    Vorbedingungen
    Karte unterstützt die übergebene pinRef
    Eingangsdaten

    •       cardSession
      (CardSession einer EGK G2)
    •       pinRef
      (PIN-Referenz der ab-/anzuschaltenden PIN, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
    •       enable [Boolean]
      (enable = true:  Erfordernis der Benutzerverifikation einschalten;
      enable = false: Erfordernis der Benutzerverifikation abschalten)
    Komponenten
    Konnektor
    Ausgangsdaten

    •       pinResult [PinResult]
      (Ergebnis von PIN-Schutz ein-/ausschalten durch PIN-Eingabe)
    •       leftTries – optional/verpflichtend nach fehlerhafter PIN
      (verbleibende Versuche)
    Standardablauf

     1. Ermittle Card = CM_CARD_LIST(cardSession)
     2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der
         Aufrufer im Besitz des Karten-Locks ist.
     3. Prüfe Card.Type = EGK und Generation ≥ 2

     4. Prüfe pinRef = MRPIN.AMTS und Card.Type = EGK
                   und Generation > 2.0
     5. Wenn enable
    A: =true:
            Atomare Operation: PIN bearbeiten inkl. Eventing und
            Ergebnisvermerk
             a.            Rufe TUC_KON_256 {
                       topic = „CARD/PIN/ENABLE_STARTED“;
                       eventType = Op;
                       severity = Info;
                       parameters = („CardHandle=$, CardType=$,
                                  ICCSN=$, CtID=$, SlotID=$, PinRef=$,
                                  PinInputCtID=$PinInputKT“);
                       doLog = false }
             b.            Aufruf des Kartenterminalkommandos „SICCT PERFORM
                 VERIFICATION“ mit der Kartenoperation „ENABLE
                 VERIFICATION REQUIREMENT” als Command-To-Perform. Es
                  ist der Parameter P1=’00’ (mit Benutzerverifikation) zu
                 verwenden. Die Anzeige am KT erfolgt entsprechend
                 TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am
                  Kartenterminal. Ersetze in displayMessage „ANW“ entsprechend
                 ANW(pinRef) gemäß Tabelle TAB_KON_838.
              c.           Setze pinResult in Abhängigkeit von Ergebnis Perform
                 Verification:
                        -          pinResult = OK für erfolgreiche Änderung
                        -          pinResult = ERROR für Nutzer-Abbruch oder
                         Bearbeitungsfehler (siehe Fehlerfälle)
                    -              pinResult = REJECTED für falsche PIN;
                         leftTries = x (bei Kartenantwort ´63 Cx´, x > 0)
                    -              pinResult = BLOCKED für gesperrte PIN (bei
                         Kartenantwort ´63 C0´)
             d.           Rufe TUC_KON_256 {
                       topic =„CARD/PIN/ENABLE_FINISHED“;
                       eventType = Op;
                       severity = Info;
                       parameters = („CardHandle=$, CardType=$,
                               ICCSN=$, CtID=$, SlotID=$, PinRef=$,
                               PinInputCtID=$PinInputKT”);
                       doLog = false }
    B: =false:
              Atomare Operation: PIN bearbeiten inkl. Eventing und
             Ergebnisvermerk
             a.             Rufe TUC_KON_256 {
                       topic = „CARD/PIN/DISABLE_STARTED“;
                       eventType = Op;
                       severity = Info;
                       parameters = („CardHandle=$, CardType=$,
                               ICCSN=$, CtID=$, SlotID=$, PinRef=$,
                               PinInputCtID=$PinInputKT“);
                       doLog = false }
             b.             Aufruf des Kartenterminalkommandos „SICCT PERFORM
                VERIFICATION“ mit der Kartenoperation „DISABLE
                VERIFICATION REQUIREMENT” als Command-To-Perform. Es
                ist der Parameter P1=’00’ (mit Benutzerverifikation) zu
                verwenden. Die Anzeige am KT erfolgt entsprechend
                TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am
                Kartenterminal. Ersetze in displayMessage „ANW“ entsprechend
                ANW(pinRef) gemäß Tabelle TAB_KON_838.
             c.             Setze pinResult in Abhängigkeit von Ergebnis Perform
                  Verification:
                         -             pinResult = OK für erfolgreiche Änderung
                         -             pinResult = ERROR für Nutzer-Abbruch oder
                           Bearbeitungsfehler (siehe Fehlerfälle)
                    -                  pinResult = REJECTED für falsche PIN;
                           leftTries = x (bei Kartenantwort ´63 Cx´, x > 0)
                    -                  pinResult = BLOCKED für gesperrte PIN

             d.            Rufe TUC_KON_256 {
                   topic = „CARD/PIN/DISABLE_FINISHED“;
                   eventType = Op;
                   severity = Info;
                   parameters = („CardHandle=$, CardType=$,
                          ICCSN=$;CtID=$, SlotID=$, PinRef=$,
                          PinInputCtID=$PinInputKT”);  
                          doLog=false}
    6. Liefere pinResult und leftTries zurück


    Varianten/
    Alternativen

    (->3) zur Optimierung kann vor Schritt 5 der PIN-Schutz geprüft werden:
     a.         pinStatus=TUC_KON_022 „Liefere PIN-Status“ { cardSession;
           pinRef }
     b.         Wenn pinStatus<>DISABLED und enable=true, dann
            pinResult=OK und -> weiter in Schritt 6
     c.         Wenn pinStatus=DISABLED und enable=false, dann
           pinResult=OK und -> weiter in Schritt 6

    Fehlerfälle

    (2) Karte ist fremd reserviert: Fehlercode 4093
    (3) Karte ist keine eGK der Generation 2 oder höher: Fehlercode 4209
    (4) PIN nicht gefunden; Karte ist eGK G2.0: Die Operation „PIN-Schutz ein-/ausschalten“ wird für MRPIN.AMTS nicht unterstützt: Fehlercode 4072
    (5) Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden: Fehlercode 4094
    (5) PIN nicht gefunden: Fehlercode 4072
    (5) PIN gesperrt: Fehlercode 4063
    (5) Zugriffsbedingung nicht erfüllt (PIN nicht abschaltbar): Fehlercode 4085

    Nichtfunktionale Anforderungen

    Keine

    Zugehörige Diagramme

    keine

    Tabelle 73: TAB_KON_838 Mapping von pinRef auf ANW

    pinRef
    ANW (max. 16 Zeichen)
    MRPIN.NFD
    Notfalldaten
    MRPIN.DPE
    Pers.Erklärungen
    MRPIN.AMTS
    Medikationsdaten
    MRPIN.GDD
    PIN•GDD

    Hinweis zu TAB_KON_838: Leerzeichen werden als "•" dargestellt.

    Tabelle 74: TAB_KON_241 Fehlercodes TUC_KON_027 „PIN-Schutz ein/ausschalten“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4063
    Security
    Error
    PIN bereits blockiert (BLOCKED)
    4072
    Technical
    Error
    ungültige PIN-Referenz PinRef
    4085
    Security
    Error
    Zugriffsbedingung nicht erfüllt
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.4.7 TUC_KON_023 „Karte reservieren“

    TIP1-A_4571

    Der Konnektor MUSS den technischen Use Case „Karte reservieren“ gemäß TUC_KON_023 umsetzen.

    Tabelle 75: TAB_KON_533 - TUC_KON_023 „Karte reservieren”

    Element
    Beschreibung
    Name
    TUC_KON_023 „Karte reservieren”
    Dem Aufrufer des TUC_KON_023 wird beim Reservieren (DoLock=Ja) der Karte zur ausschließlichen Nutzung ein Lock zugeordnet. Wird der TUC-KON_023 mit diesem Lock zum Freigeben der Reservierung (DoLock=Nein) aufgerufen, dann erlischt das Lock und die ausschließliche Nutzung wird beendet. Der Scope der Kartenreservierung wird vom Aufrufer des TUC_KON_023 gesteuert.
    Das Lock ist Konnektor-intern. Es darf nicht außerhalb des Konnektors referenzierbar sein. Zwei verschiedene Operationsaufrufe am Konnektor dürfen nie ein identisches Lock haben.
    Der Konnektor MUSS sicherstellen, dass auch im Fehlerfall die Reservierung zu einem Lock aufgehoben wird. Ein Lock darf nicht dauerhaft bestehen.
    Beschreibung
    Reservierung der Karte
    Auslöser
    • Aufruf des Use Case im Rahmen von technischen Use Cases der
      Basisdienste des Konnektors

    • Aufruf des Use Cases durch ein Fachmodul im Konnektor
    Vorbedingungen
    Keine
    Eingangsdaten
    • cardSession
    • doLock [Boolean]
      (Zielzustand der Karte; true = reserviert, false = freigegeben)

    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
     1. Ermittle Card = CM_CARD_LIST(cardSession)
     2. Wenn doLock
    A: = true:
           i.            Prüfe, dass der zur cardSession gehörenden Karte kein
               Lock zugeordnet ist

           ii.           Dem Aufrufer wird ein Lock auf die zur cardSession
               gehörende Karte zugeordnet. Es wird nicht explizit als
               Ausgangsdatum modelliert, sondern der Aufrufer hat das Lock
               durch die Zuordnung, muss es aber nicht verwalten.

    B: = false:
           i.            Prüfe, dass der Aufrufer für die zur cardSession gehörende
               Karte ein Lock hat.

           ii.           Das der Karte zugeordnete Lock wird gelöscht.

    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    (2Ai) Karte bereits reserviert, Fehlercode 4093
    (2Bi) Karte nicht durch Aufrufer reserviert, Fehlercode 4001
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 76: TAB_KON_534 Fehlercodes TUC_KON_023 „Karte reservieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4001
    Technical
    Error
    interner Fehler
    4093
    Technical
    Error
    Karte bereits reserviert

    <=

    4.1.5.4.8 TUC_KON_005 „Card-to-Card authentisieren“

    Die C2C-Authentisierung erfolgt konform zu den in [gemSpec_COS#15] festgelegten Authentisierungsprotokollen.

    Definition Quellkarte/Zielkarte:

    Bei einseitiger Card-to-Card-Authentisierung ohne Aushandlung eines Session Key ist die Quellkarte diejenige, die die Rolle des Karteninhabers bzw. der Organisation gemäß [gemSpec_PKI_TI#Tab_PKI_254] gegenüber der anderen Karte nachweist, z. B. der HBA bei der Freischaltung einer eGK.

    Bei gegenseitiger Card-to-Card-Authentisierung ohne Aushandlung eines Session Key erfolgen nach einander zwei einseitige Card-to-Card-Authentisierungen mit vertauschten Rollen. Quell- und Zielkarte habe daher für den Gesamtablauf keine nähere Bedeutung.

    Bei Card-to-Card-Authentisierung mit Aushandlung eines Session Key ist die Quellkarte diejenige, die die SM-APDUs produzieren kann, also die SMC (-KT oder -K).

    Die Zielkarte ist jeweils die Karte, die nicht die Quellkarte ist.

    TIP1-A_4572

    Der Konnektor MUSS den technischen Use Case „Card-to-Card authentisieren“ gemäß TUC_KON_005 umsetzen.
    Die Card-to-Card-Authentisierung zwischen zwei Karten, bei der eine Karte der Generation 1+ angehört MUSS das RSA-Verfahren verwenden.
    Die Card-to-Card-Authentisierung zwischen zwei Karten der Generation 2 MUSS das Verfahren der elliptischen Kurven verwenden.

    Tabelle 77: TAB_KON_096 – TUC_KON_005 „Card-to-Card authentisieren”

    Element
    Beschreibung
    Name
    TUC_KON_005 „Card-to-Card authentisieren“
    Beschreibung
    Durchführung einer Card-to-Card-Authentisierung
    Auslöser
    • Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors
    • Aufruf des Use Cases durch ein Fachmodul im Konnektor
    Vorbedingungen
    Wert von Source_CARDSESSION.AUTHSTATE: wenn Quellkarte
    a) ein HBA ist: CHV; PIN.CH, verifiziert
    b) eine SMC-B ist: CHV; PIN.SMC verifiziert
    Eingangsdaten
    • sourceCardSession
      (Quellkarte)

    • targetCardSession
      (Zielkarte)

    • authMode (gemäß Tabelle TAB_KON_673)
    Komponenten
    Karten, Konnektor, Kartenterminal
    Ausgangsdaten
    Keine
    Standardablauf
    1.     Ermittle sCard = CM_CARD_LIST(sourceCardSession)
    2.     Ermittle tCard = CM_CARD_LIST(targetCardSession)
    3.     Prüfe, dass der Quellkarte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz auf das Lock der Quellkarte ist.
      Prüfe, dass der
      Zielkarte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz auf das Lock der Zielkarte ist.
    4.     Prüfe Aufrufparameter auf erlaubte Kombination gemäß Tabelle TAB_KON_674
    5.     Wenn das zu verwendende CV-Zertifikat der Quellkarte ein CV-Zertifikat der Generation 2 oder höher ist, dann prüfe sein  Ausstellungsdatum (CED) gegen die aktuelle Zeit
    6.     Wenn Card.TYP=eGK UND Card.Version=Generation1+, dann prüfe, ob aktuelles System-Datum < 01.01.2019 ist
    7.     Wähle Key-Referenzen gemäß Tabelle TAB_KON_674
    8.     Prüfe pinRef/keyRef in sCard.CARDSESSION.AUTHSTATE und tCard.CARDSESSION.AUTHSTATE für adressierte Schlüssel wie in Zugriffsbedingung der Karten definiert vorhanden
    9.     Durchführung der Authentisierung gemäß Tabelle TAB_KON_673 mit Key-Referenzen gemäß Tabelle TAB_KON_674
    10.     Ergänze targetCardSession.AUTHSTATE mit tKeyRef und Rolle aus sKeyRef (CHA bzw. CHAT aus dem EndEntity-CV-Zertifikat der Quellkarte)
    Varianten/
    Alternativen

    (9) Wenn der für die CA-Zertifikatsprüfung zu selektierende CVC-Root-Key auf der Zielkarte nicht vorhanden ist (Returncode des Kartenkommandos „MANAGE SECURITY ENVIRONMENT“ ist ’6A 88’), dann muss der Konnektor:
     a)      das oder die passenden Cross-CV-Zertifikate aus dem Truststore
        auswählen

     b)      mit dem Kartenkommando „PSO Verify Certificate“ jedes
        ausgewählte Cross-CV-Zertifikat durch die Zielkarte prüfen lassen.
         Dadurch wird der im Cross-CV-Zertifikat enthaltene öffentliche
         Schlüssel an die Zielkarte übertragen. Die Zielkarte speichert den
        darin enthaltenen neuen CVC-Root-Key.

     c)      den neuen CVC-Root-Key auf der Zielkarte selektieren
     d)      den Standardablauf der C2C-Authentisierung fortsetzen
    (9) Wenn tCard.TYPE=EGK und AuthMode=gegenseitig,
          dann Echtheitsprüfung der eGK durch den Konnektor:

     a)      Freischaltung der EGK durch den HBA/die SMC-B:
         Durchführen der Authentisierung gemäß Tabelle TAB_KON_673 mit Key-Referenzen gemäß Tabelle TAB_KON_674 aber mit AuthMode=einseitig

     b)      Konnektor liest das CA-Zertifikat EF.C.CA_eGK.CS (G1+) bzw.
         C.CA_eGK.CS.E256 (G2)

     c)      Konnektor liest das End-Entity-Zertifikat der EGK
        EF.C.eGK.AUT_CVC (G1+) bzw. EF.C.eGK.AUT_CVC.E256 (G2)

     d)      Konnektor prüft das CVC-EE-Zertifikat mit TUC_KON_042 „CV-
        Zertifikat prüfen“ {
             certificate = C.eGK.AUT_CVC/C.eGK.AUT_CVC.E256;
             caCertificate  = C.CA_eGK.CS/C.CA_eGK.CS.E256 }

     e)      Konnektor erzeugt Zufallszahl
     f)       Konnektor selektiert den PrK.eGK.AUT_CVC (G1+) bzw.
      PrK.eGK.AUT_CVC.E256 (G2) und stellt abhängig von der Version
       der eGK den Algorithmus auf der eGK ein (MSE Set)

     g)      Konnektor sendet Konkatenation aus Zufallszahl und
       CARD.ICCSN mit dem Befehl „INTERNAL AUTHENTICATE“ an die
       eGK

     h)      Konnektor wertet das von der Karte erhaltene Chiffrat aus

    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (3) Eine Karte ist fremd reserviert, Fehlercode 4093
    (5) Zertifikat der Quellkarte fehlerhaft. Ausstellungsdatum liegt in der Zukunft; Fehlercode 4233
    (6) eGK G1+ ausgealtert, Fehlercode 4192
    (8) Nötige PIN, bzw. KeyRef ist nicht verifiziert, Fehlercode 4085
    (9) Je nachdem, welche Karte den Fehler verursachte, wird zum ursprünglichen Fehler (Fehlercode gemäß [gemSpec_COS]) im Error-Trace (welcher an erster Stelle im Falle des HBA z. B. bereits ein Fehler bezüglich PIN-Verifikation enthalten kann) noch ein weiterer mit Code 4056 oder 4057 hinzugefügt. Kann der Fehler nicht eindeutig einer der beiden Karten zugeordnet so wird Error-Code 4048 verwendet.

    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    Keine

    Tabelle 78: TAB_KON_673 AuthMode für C2C

    AuthMode
    Definition des Ablaufs
    einseitig
    Externe oder Interne Authentisierung
    ([gemSpec_COS#15.1] oder [gemSpec_COS#15.2], passend zu den Zugriffsregeln der beteiligten CVC)

    gegenseitig
    Card-2-Card-Authentisierung ohne Sessionkey-Aushandlung ([gemSpec_COS#15.3])
    gegenseitig+TC
    Card-2-Card-Authentisierung mit Sessionkey-Aushandlung zur Etablierung eines Trusted Channels ([gemSpec_COS#15.4])

    Tabelle 79: TAB_KON_674 Erlaubte Parameterkombinationen und resultierende CV-Zertifikate für C2C

    Quellkarte
    Zielkarte
    AuthMode
    sKeyRef
    tKeyRef
    Fachlicher
    UseCase

    HBA
    oder
    SM-B

    eGK G1+
    einseitig
    {HPC.AUTR_
    CVC.R2048 |
    SMC.AUTR_
    CVC.R2048}


    Freischaltung
    eGK

    HBA
    oder
    SM-B

    eGK G1+
    gegen
    seitig

    {HPC.AUTR_
    CVC.R2048 |
    SMC.AUTR_
    CVC.R2048}

    eGK.AUT_
    CVC.R2048

    Freischaltung
    eGK mit
    Echtheits
    prüfung eGK

    HBA
    oder
    SM-B

    eGK G2
    einseitig
    {HPC.AUTR_
    CVC.E256 |
    SMC.AUTR_
    CVC.E256}


    Freischaltung
    eGK

    HBA
    oder
    SM-B

    eGK G2
    gegen
    seitig

    {HPC.AUTR_
    CVC.E256 |
    SMC.AUTR_
    CVC.E256}

    eGK.AUT_
    CVC.E256

    Freischaltung
    eGK mit
    Echtheits
    prüfung eGK

    SMC-K
    HBA
    gegen
    seitig+TC

    SAK.AUTD_
    CVC.E256

    HPC.AUTD_
    SUK_CVC.E256

    DTBS-
    Übertragung
    bei QES

    SMC-KT
    HBA
    gegen
    seitig+TC

    SMC.AUTD_
    RPS_CVC.E256

    HPC.AUTD_
    SUK_CVC.E256

    Remote-PIN
    SMC-KT
    SM-B
    gegen
    seitig+TC

    SMC.AUTD_
    RPS_CVC.E256

    SMC.AUTD_
    RPE_CVC.E256

    Remote-PIN

    Tabelle 80: TAB_KON_535 Fehlercodes TUC_KON_005 „Card-to-Card authentisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4048
    Technical
    Error
    Fehler bei der C2C-Authentisierung
    4056
    Technical
    Error
    Fehler bei der C2C-Authentisierung, Quellkarte
    4057
    Technical
    Error
    Fehler bei der C2C-Authentisierung, Zielkarte
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4192
    Security
    Error
    C2C mit eGK G1+ ab 01.01.2019  nicht mehr gestattet
    4233
    Security
    Error
    Ausstellungsdatum des Zertifikats liegt in der Zukunft;

    <=

    4.1.5.4.9 TUC_KON_202 „LeseDatei“

    TIP1-A_4573

    Der Konnektor MUSS den technischen Use Case „LeseDatei“ gemäß TUC_KON_202 umsetzen.

    Tabelle 81: TAB_KON_218 – TUC_KON_202 „LeseDatei“

    Element
    Beschreibung
    Name
    TUC_KON_202 „LeseDatei“
    Beschreibung
    Transparente Datei oder Teile davon lesen
    Auslöser
    • Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors
    • Aufruf des Use Cases durch ein Fachmodul im Konnektor
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu lesenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu lesenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • offset – optional/nur verwendbar, wenn fileIdentifier angegeben ist
      (Startposition innerhalb der Datei)
    • length – optional
      (Längenangabe, um den Zugriff auf Teile einer Datei einzuschränken)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    • content
      (Gelesene Daten)
    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(cardSession)
    2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3. Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    4. Selektiere Verzeichnis und Datei
    5. Lies Daten über Kartenkommando „READ BINARY“ unter Berücksichtigung von Offset- und Längenangaben
    6. Die gelesenen Daten werden an den Aufrufer zurückgegeben
    Varianten/
    Alternativen
    Wenn Card.TYPE = KVK, sendet der Konnektor in diesem Fall ein "Read Binary" im Sinne von SICCT 1.2.1, 5.5.8.1 "Kommandos für synchrone Chipkarten".
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Karte ist fremd reserviert, Fehlercode 4093
    (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5) Verzeichnis deaktiviert, Fehlercode 4086
    (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 82: TAB_KON_536 Fehlercodes TUC_KON_202 „LeseDatei“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten


    <=

    4.1.5.4.10 TUC_KON_203 „SchreibeDatei“

    TIP1-A_4574

    Der Konnektor MUSS den technischen Use Case „SchreibeDatei“ gemäß TUC_KON_203 umsetzen.

    Tabelle 83: TAB_KON_219 – TUC_KON_203 „SchreibeDatei“

    Element
    Beschreibung
    Name
    TUC_KON_203 „SchreibeDatei“
    Beschreibung
    Daten in transparente Datei schreiben
    Auslöser
    • Aufruf durch Fachmodul
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen.
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu lesenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu lesenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • offset– optional
      (Startposition innerhalb der Datei, default: 0)  
    • length – optional
      (Längenangabe, um den Zugriff auf Teile einer Datei einzuschränken; default: alles ab offset)
    • dataToBeWritten
      (Zu schreibende Daten)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe Card.TYPE <> KVK
    3.      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    4.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    5.      Selektiere Verzeichnis
    6.      Selektiere Datei mittels SELECT mit P2=‘04‘ (Selektieren einer Datei, Antwortdaten mit FCP)
    7.      Ermittle size (Größe der selektierten Datei in Byte) mit size = numberOfOctet aus FCP
    8.      Wenn size – offset  >= Größe von dataToBeWritten in Byte,
      dann schreibe dataToBeWritten mittels Kartenkommando “UPDATE BINARY“ unter Berücksichtigung von Offset- und Längenangaben
    Varianten/
    Alternativen
    keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Schreibzugriff auf KVK nicht gestattet, Fehlercode 4085
    (3) Karte ist fremd reserviert, Fehlercode 4093
    (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5) Verzeichnis oder Datei existiert nicht, Fehlercode 4087
    (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    (6) Ausgewählte Datei ist nicht transparent, Fehlercode 4089
    (6) Verzeichnis deaktiviert, Fehlercode 4086
    (8) dataToBeWritten sind größer als der zur Verfügung stehende Speicherplatz, Fehlercode 4247
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 84: TAB_KON_537 Fehlercodes TUC_KON_203 „Schreibe Datei“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4087
    Technical
    Error
    Datei nicht vorhanden
    4089
    Technical
    Error
    Datei ist vom falschen Typ
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4247
    Technical
    Error
    Speicherplatz auf der Karte nicht ausreichend


    <=

    4.1.5.4.11 TUC_KON_204 „LöscheDateiInhalt“

    TIP1-A_5476

    Der Konnektor MUSS den technischen Use Case „LöscheDateiInhalt“ gemäß TUC_KON_204 umsetzen.

    Tabelle 85: TAB_KON_204 – TUC_KON_204 „LöscheDateiInhalt“

    Element
    Beschreibung
    Name
    TUC_KON_204 „LöscheDateiInhalt“
    Beschreibung
    Inhalt einer transparenten Datei löschen
    Auslöser
    • Aufruf des Use Cases durch ein Fachmodul im Konnektor
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu bearbeitenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu bearbeitenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • offset – optional
      (Position, ab der der Inhalt gelöscht werden soll. Default: 0)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    keine
    Standardablauf
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe Card.TYPE <> KVK
    3.      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz des Karten-Locks ist.
    4.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    5.      Selektiere Verzeichnis und Datei
    6.      Lösche Inhalt der selektierten Datei über Kartenkommando „ERASE BINARY“, ggf. ab angegebenem Offset, sonst ab Anfang
    Varianten/
    Alternativen
    keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Karte ist keine eGK der Generation 2 oder höher: Fehlercode 4209 (3) Karte ist fremd reserviert, Fehlercode 4093
    (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5) Verzeichnis oder Datei existiert nicht, Fehlercode 4087
    (6) Ausgewählte Datei ist nicht transparent, Fehlercode 4089
    (6) Verzeichnis deaktiviert, Fehlercode 4086
    (5-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 86: TAB_KON_785 Fehlercodes TUC_KON_204 „LöscheDateiInhalt“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4087
    Technical
    Error
    Datei nicht vorhanden
    4089
    Technical
    Error
    Datei ist vom falschen Typ
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.4.12 TUC_KON_209 „LeseRecord“

    TIP1-A_4575

    Der Konnektor MUSS den technischen Use Case „LeseRecord“ gemäß TUC_KON_209 umsetzen.

    Tabelle 87: TAB_KON_538 – TUC_KON_209 „LeseRecord“

    Element
    Beschreibung
    Name
    TUC_KON_209 „LeseRecord"
    Beschreibung
    Daten aus strukturierter Datei lesen
    Auslöser
    • Aufruf durch Fachmodul
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu lesenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu lesenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • recordNumber
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    • content
      (Inhalt des Records)
    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(cardSession)
    2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt
    3. Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    4. Selektiere Verzeichnis und ggf. Datei
    5. Lies Daten über Kartenkommando „READ RECORD“ unter Berücksichtigung von recordNumber
    6. Rückgabe der Daten an den Aufrufer
    Varianten/
    Alternativen
    keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Karte ist fremd reserviert, Fehlercode 4093
    (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (4) Verzeichnis oder Datei oder Record existiert nicht, Fehlercode 4087
    (5) Wenn Karte WrongFileType liefert, Fehlercode 4089
    (5) Verzeichnis deaktiviert, Fehlercode 4086
    (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 88: TAB_KON_539 Fehlercodes TUC_KON_209 „LeseRecord“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4087
    Technical
    Error
    Datei nicht vorhanden
    4089
    Technical
    Error
    Datei ist vom falschen Typ
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten


    <=

    4.1.5.4.13 TUC_KON_210 „SchreibeRecord“

    TIP1-A_4576

    Der Konnektor MUSS den technischen Use Case „SchreibeRecord“ gemäß TUC_KON_210 umsetzen.

    Tabelle 89: TAB_KON_224 – TUC_KON_210 „SchreibeRecord“

    Element
    Beschreibung
    Name
    TUC_KON_210 „SchreibeRecord"
    Beschreibung
    Daten in lineare Datei schreiben
    Auslöser
    • Aufruf durch Fachmodul
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu bearbeitenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu bearbeitenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • recordNumber
    • dataToBeWritten
      (Zu schreibende Daten)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    keine
    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(cardSession)
    2. Prüfe Card.TYPE <> KVK
    3. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    4. Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    5. Selektiere Verzeichnis und ggf. Datei
    6. Schreibe Daten über Kartenkommando „UPDATE RECORD“ unter Berücksichtigung von recordNummer
    Varianten/
    Alternativen
    keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Schreibzugriff auf KVK nicht gestattet, Fehlercode 4085
    (3) Karte ist fremd reserviert, Fehlercode 4093
    (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5) Verzeichnis, Datei existiert nicht, Fehlercode 4087
    (5-6) Verzeichnis deaktiviert, Fehlercode 4086
    (4-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 90: TAB_KON_540 Fehlercodes TUC_KON_210 „SchreibeRecord“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4087
    Technical
    Error
    Datei nicht vorhanden
    4088
    Technical
    Error
    Datensatz zu groß
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten


    <=

    4.1.5.4.14 TUC_KON_211 „LöscheRecordInhalt“

    TIP1-A_5477

    Der Konnektor MUSS den technischen Use Case „LöscheRecordInhalt“ gemäß TUC_KON_211 umsetzen.

    Tabelle 91: TAB_KON_211 – TUC_KON_211 „LöscheRecordInhalt“

    Element
    Beschreibung
    Name
    TUC_KON_211 „LöscheRecordInhalt“
    Beschreibung
    Inhalt eines Records einer strukturierten Datei löschen
    Auslöser
    •   Aufruf des Use Case im Rahmen von technischen Use Cases der Basisdienste des Konnektors
    •   Aufruf des Use Cases durch ein Fachmodul im Konnektor
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu bearbeitenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu bearbeitenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • recordNumber
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    keine
    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(cardSession)
    2. Prüfe Card.TYPE <> KVK
    3. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz des Karten-Locks  ist.
    4. Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    5. Selektiere Verzeichnis und Datei
    6. Lösche Recordinhalt (identifiziert durch recordNumber) der selektierten Datei über Kartenkommando „ ERASE RECORD“
    Varianten/
    Alternativen
    keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Karte ist keine eGK der Generation 2 oder höher: Fehlercode 4209
    (3) Karte ist fremd reserviert, Fehlercode 4093
    (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5) Verzeichnis, Datei oder Record existiert nicht, Fehlercode 4087
    (6) Verzeichnis deaktiviert, Fehlercode 4086
    (6) Record nicht vorhanden, Fehlercode 4091
    (5-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 92: TAB_KON_786 Fehlercodes TUC_KON_211 „LöscheRecordInhalt“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4087
    Technical
    Error
    Datei nicht vorhanden
    4091
    Technical
    Error
    Record nicht vorhanden
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.
    <=

    4.1.5.4.15 TUC_KON_214 „FügeHinzuRecord“

    TIP1-A_4577

    Der Konnektor MUSS den technischen Use Case „FügeHinzuRecord“ gemäß TUC_KON_214 umsetzen.

    Tabelle 93: TAB_KON_228 – TUC_KON_214 „FügeHinzuRecord“

    Element
    Beschreibung
    Name
    TUC_KON_214 „FuegeHinzuRecord"
    Beschreibung
    Daten in lineare Datei anfügen
    Auslöser
    • Aufruf durch Fachmodul
    • TUC_KON_006
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu bearbeitenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu bearbeitenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • dataToBeWritten
      (Zu schreibende Daten)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    keine
    Standardablauf
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe Card.TYPE <> KVK
    3.      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    4.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    5.      Selektiere Verzeichnis und ggf. Datei
    6.      Schreibe Daten über Kartenkommando „APPEND RECORD“
    Varianten/
    Alternativen
    keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Schreibzugriff auf KVK nicht gestattet, Fehlercode 4085
    (3) Karte ist fremd reserviert, Fehlercode 4093
    (4) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5-6) Verzeichnis, Datei existiert nicht, Fehlercode 4087
    (6) Verzeichnis deaktiviert, Fehlercode 4086
    (5-6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 94: TAB_KON_541 Fehlercodes TUC_KON_214 „FügeHinzuRecord“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4087
    Technical
    Error
    Datei nicht vorhanden
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    <=

    4.1.5.4.16 TUC_KON_215 „SucheRecord“

    TIP1-A_4578

    Der Konnektor MUSS den technischen Use Case „SucheRecord“ gemäß TUC_KON_215 umsetzen.

    Tabelle 95: TAB_KON_229 – TUC_KON_215 „SucheRecord“

    Element
    Beschreibung
    Name
    TUC_KON_215 „SucheRecord"
    Beschreibung
    Daten in linearer Datei suchen
    Auslöser
    • Aufruf durch Fachmodul
    Vorbedingungen
    Die Karte MUSS den nötigen Sicherheitszustand für den Zugriff besitzen
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu bearbeitenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu bearbeitenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich die Datei befindet)
    • pattern
      (SuchMuster)
    • recordNumber – optional; default = 1
      (Recordnummer, bei der Suche beginnen soll) ()
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    • numbersFound
      (Liste: Nummern der Records, die dem SuchMuster entsprechen)
    Standardablauf
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3.      Prüfe PinRef/KeyRef in CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    4.      Selektiere Verzeichnis und ggf. Datei
    5.      Sende Kartenkommando „SEARCH RECORD“ mit SuchMuster pattern unter Berücksichtigung von recordNumber
    6.      Liefere Antwort der Karte zurück
    Varianten/
    Alternativen
    Keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD-Sekunden, Fehlercode 4094
    (2) Karte ist fremd reserviert, Fehlercode 4093
    (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (4-5) Verzeichnis, Datei existiert nicht, Fehlercode 4087
    (5) Verzeichnis deaktiviert, Fehlercode 4086
    (4-5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 96: TAB_KON_542 Fehlercodes TUC_KON_215 „SucheRecord“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4086
    Technical
    Error
    Verzeichnis deaktiviert
    4087
    Technical
    Error
    Datei nicht vorhanden
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten


    <=

    4.1.5.4.17 TUC_KON_018 „eGK-Sperrung prüfen“

    TIP1-A_4579

    Der Konnektor MUSS den technischen Use Case „eGK-Sperrung prüfen“ gemäß TUC_KON_018 umsetzen.

    Tabelle 97: TAB_KON_110 - TUC_KON_018 „eGK-Sperrung prüfen“

    Element
    Beschreibung
    Name
    TUC_KON_018 „eGK-Sperrung prüfen“
    Beschreibung
    Es wird geprüft, dass DF.HCA (Health Care Application) der eGK nicht gesperrt ist und optional, dass das AUT-Zertifikat im DF.ESIGN gültig ist.
    Für eine Karte ab der Generation G2.1 wird das AUT-Zertifikat (ECC) geprüft.
    Für eine Karte der Generation G2.0 wird das AUT-Zertifikat (RSA) geprüft.

    Auslöser
    Aufruf durch Fachmodul im Konnektor
    Vorbedingungen
    keine
    Eingangsdaten
    • cardSession
    • checkHcaOnly [Boolean] - optional; default = false
      (Prüfung auf die Frage beschränken, ob auf DF.HCA zugegriffen werden kann)
    Komponenten
    Konnektor, Kartenterminal, eGK
    Ausgangsdaten
    • Karte gesperrt: true | false
    • Status – optional/wenn checkHcaOnly = false
      • DF.HCA gesperrt: true | false
      • Ergebnis der Offline-Prüfung des C.CH.AUT-Zertifikats:
        gültig | ungültig

      • Sperrstatus des C.CH.AUT-Zertifikats:
        gut | gesperrt | nicht ermittelbar

    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(cardSession)
    2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3. Selektiere DF.HCA :
      1. Wenn die Karte ’90 00’ zurückmeldet, war das Selektieren möglich: DF.HCA gesperrt = false
      2. In allen anderen Fällen war das Selektieren nicht fehlerfrei möglich: DF.HCA gesperrt = true
    4. Wenn checkHcaOnly = true
      Beende TUC, liefere Status.
    5. Ermittle Zertifikatsobjekt (fileIdentifier und folder) für C.AUT der Karte unter Berücksichtigung des kryptographischen Verfahrens crypt gemäß TAB_KON_858. 
      Für eine Karte ab der Generation G2.1 setze crypt=ECC.
      Für eine Karte der Generation G2.0 setze crypt=RSA.
      Rufe Cert = TUC_KON_216 „LeseZertifikat“ {cardSession; fileIdentifier; folder}
    6. Bestimme per Aufruf von TUC_KON_037 „Zertifikat prüfen“
      1. das Ergebnis der Offline-Prüfung des C.CH.AUT-Zertifikats (gültig | ungültig) sowie
      2. den Sperrstatus des C.CH.AUT-Zertifkats
        (gut | gesperrt | nicht ermittelbar).
    7. Die Karte ist gesperrt = true, wenn
      1. DF.HCA gesperrt = true oder
      2. Ergebnis der Offline-Prüfung des
        C.CH.AUT-Zertifikats = ungültig oder
      3. Sperrstatus des C.CH.AUT-Zertifkats = gesperrt.
        In allen anderen Fällen ist die Karte gesperrt = false.
    Varianten/
    Alternativen

    keine
    Fehlerfälle
    (2) Karte ist fremd reserviert, Fehlercode 4093
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 98: TAB_KON_239 Fehlercodes TUC_KON_018 „eGK-Sperrung prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet

    <=

    4.1.5.4.18 TUC_KON_006 „Datenzugriffsaudit eGK schreiben“

    TIP1-A_4580

    Der Konnektor MUSS den technischen Use Case „Datenzugriffsaudit eGK schreiben“ gemäß TUC_KON_006 umsetzen.

    Tabelle 99: TAB_KON_108 - TUC_KON_006 „Datenzugriffsaudit eGK schreiben“

    Element
    Beschreibung
    Name
    TUC_KON_006 „Datenzugriffsaudit eGK schreiben“
    Beschreibung
    Zugriff auf eGK in EF.Logging protokollieren.
    Auslöser
    Aufruf durch ein Fachmodul
    Vorbedingungen
    Keine
    Eingangsdaten
    • cardSession
      (CardSession einer eGK)

    • sourceCardSession
      (HBA/SMC-B, der/die für den eGK-Zugriff verwendet wird)

    • dataType
      (zugreifende Anwendung, siehe [gem_Spec_Karten_Fach_TIP#4.1 – Tabelle Tab_Karten_Fach_TIP_010 _StrukturEF.Logging – Struktur der Rekords der Datei EF.Logging]

    • accessType
      (Zugriffsart, siehe ebenda)

    Komponenten
    eGK, HBA/SMC, Konnektor, Kartenterminal
    Ausgangsdaten
    Keine
    Standardablauf
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe Card.TYPE = EGK
    3.      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    4.      Wenn KeyRef in CARDSESSION.AUTHSTATE für DF.HCA.EF.LOGGING nicht mit passender Rolle vorhanden: Rufe TUC_CON_005 „Card-to-Card authentisieren“ {
         sourceCardSession;
         targetCardSession = cardSession;
         authMode = einseitig}

    5.      Erzeuge Loggingdaten gemäß [gem_Spec_Karten_Fach_TIP#4.1 – Tabelle Tab_Karten_Fach_TIP_010_StrukturEF.Logging – Struktur der Rekords der Datei EF.Logging]
    6.      Rufe TUC_KON_214 „FügeHinzuRecord“ {
          cardSession =$cardSession;
          folder = MF;
          
      fileIdentifier = DF.HCA/EF.Logging;
          dataToBeWritten = Loggingdaten }

    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    (2) Protokoll nur für eGK gestattet, Fehlercode 4251
    (3) Karte ist fremd reserviert, Fehlercode 4093
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 100: TAB_KON_238 Fehlercodes TUC_KON_006 „Datenzugriffsaudit eGK schreiben“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4251
    Technical
    Error
    Protokoll nur für eGK gestattet

    <=

    4.1.5.4.19 TUC_KON_218 „Signiere“

    TIP1-A_4581

    Der Konnektor MUSS den technischen Use Case „Signiere“ gemäß TUC_KON_218 umsetzen.

    Tabelle 101: TAB_KON_231 – TUC_KON_218 „Signiere“

    Element
    Beschreibung
    Name
    TUC_KON_218 „Signiere“
    Beschreibung
    Dieser Use Case beschreibt das Anwenden eines privaten Schlüssels einer Karte zur Signatur oder Authentisierung.
    Auslöser
    • Aufruf einer der Operationen SignDocument des Signaturdienstes oder ExternalAuthenticate des Authentifizierungsdienstes durch das Clientsystem.
    • Aufruf durch Fachmodul
    Vorbedingungen
    Zugriffsbedingung für referenzierten Schlüssel MUSS erfüllt sein
    Eingangsdaten
    • cardSession
    • pinRef
      (PIN-Referenz, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
    • keyRef
      (Referenz auf den privaten Schlüssel, mit dem signiert werden soll, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
    • algorithmusId
      (einer der laut Objektspezifikation für diesen Schlüssel zulässigen algorithmIdentifier)
    • dataToBeSigned
      (Zu signierende Daten, Hashwert)
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    • chiffrat
      (Signatur)
    Standardablauf
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3.      Prüfe pinRef in CARDSESSION.AUTHSTATE vorhanden:
    4.      Setze keyRef und algorithmusId der Karte
    5.      Sende „PSO: COMPUTE DS“ mit dataToBeSigned an Karte
    6.      Gib chiffrat an den Aufrufer zurück
    Varianten/
    Alternativen
    Keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Karte ist fremd reserviert, Fehlercode 4093
    (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 102: TAB_KON_543 Fehlercodes TUC_KON_218 „Signiere“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    <=

    4.1.5.4.20 TUC_KON_219 „Entschlüssele“

    TIP1-A_4582

    Der Konnektor MUSS den technischen Use Case „Entschlüssele“ gemäß TUC_KON_219 umsetzen.

    Tabelle 103: TAB_KON_232 – TUC_KON_219 „Entschlüssele“

    Element
    Beschreibung
    Name
    TUC_KON_219 „Entschlüssele“
    Beschreibung
    Dieser Use Case beschreibt das Anwenden eines privaten Schlüssels einer Karte zur Entschlüsselung.
    Auslöser
    • Aufruf durch Fachmodul
    Vorbedingungen
    Zugriffsbedingung für referenzierten Schlüssel muss erfüllt sein
    Eingangsdaten
    • cardSession
    • pinRef
      (Referenz auf die PIN, mit der der Entschlüsselungsschlüssel freigeschaltet werden kann, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps)
    • keyRef
      (Referenz auf den privaten Schlüssel, mit dem entschlüsselt werden soll, gemäß der Objektsystem-Spezifikation des jeweiligen Kartentyps.)
    • algorithmusId
      (einer der für diesen Schlüssel zulässigen algorithmIdentifier)
    • encryptedData
      (Zu entschlüsselnde Daten, Chiffrat)
    Komponenten
    Karte(n), Kartenterminal, Konnektor
    Ausgangsdaten
    • plainData
      (Entschlüsselte Daten)
    Standardablauf
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3.      Prüfe pinRef in CARDSESSION.AUTHSTATE vorhanden:
    4.      Selektiere DF, in dem der private Schlüssel (keyRef) liegt, falls er noch nicht selektiert ist.
    5.      Setze Schlüssel (keyRef) und algorithmusId.
    6.      Sende encryptedData mittels Kommandos PSO: DECIPHER.
    7.      gib plainData an den Aufrufer zurück
    Varianten/
    Alternativen
    Keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Karte ist fremd reserviert, Fehlercode 4093
    (3) Nötige PIN ist nicht verifiziert, Fehlercode 4085
    (5) Schlüssel nicht vorhanden, Fehlercode 4079
    (6) Fehler im Chiffrat: Fehlercode 4069
    (4, 6) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Varianten/
    Alternativen
    Keine
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 104: TAB_KON_210 Fehlercodes TUC_KON_219 „Entschlüssele“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4069
    Technical
    Error
    korruptes Chiffrat bei asymmetrischer Entschlüsselung
    4079
    Technical
    Error
    Schlüsseldaten fehlen
    4085
    Security
    Error
    Zugriffsbedingungen nicht erfüllt
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    <=

    4.1.5.4.21 TUC_KON_200 „SendeAPDU“

    TIP1-A_4583

    Der Konnektor MUSS den technischen Use Case „SendeAPDU“ gemäß TUC_KON_200 umsetzen.

    Tabelle 105: TAB_KON_215 TUC_KON_200 „SendeAPDU“

    Element
    Beschreibung
    Name
    TUC_KON_200 „SendeAPDU“
    Beschreibung
    Dieser Use Case beschreibt das Senden einer APDU an eine Chipkarte bzw. an ein Kartenterminal und das Empfangen der Antwort.
    Auslöser
    • Aufruf durch Fachmodul
    Vorbedingungen
    Zugriffsbedingungen für das Kommando müssen in der Karte erfüllt sein und Karte muss für exklusiven Zugriff reserviert worden sein
    Eingangsdaten
    • cardSession – optional/verpflichtend, wenn die APDU an die Karte gerichtet ist
    • ctId – optional/verpflichtend, wenn die APDU an das Kartenterminal gerichtet ist
      (Kartenterminalidentifikator für Kommandos an das Kartenterminal)
    • commandAPDU
      (versandfertige APDU (Bytefolge), in dem die Parameter {CLA, INS, P1,P2, Data (
      optional) Le(optional) } gesetzt sind.)
    Komponenten
    Karte(n), Kartenterminal, Konnektor
    Ausgangsdaten
    • responseAPDU
      (Antwort der Chipkarte oder des Kartenterminals, Bytefolge)

    Standardablauf
    A. cardSession ist gegeben
    1.      Ermittle Card = CM_CARD_LIST(cardSession)
    2.      Prüfe, dass der Aufrufer für die zur cardSession gehörenden Karte ein Lock hat.
    3.      commandAPDU wird über das Kartenterminal an die Zielkarte gesendet
    4.      die Antwort (responseAPDU) der Zielkarte wird an den Aufrufer zurückgegeben.
    B. ctId ist gegeben
    1.      Sende commandAPDU an das Kartenterminal ctId
    2.      gib die Antwort responseAPDU des Kartenterminals an den Aufrufer zurück
    Varianten/Alternativen
    • Soll Secure Messaging verwendet werden, MUSS vorher TUC_KON_023 „Karte reservieren“ aufgerufen werden
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Der Aufrufer ist nicht im Besitz des Karten-Locks, Fehlercode 4232
    (3) Kommunikationsfehler mit dem Kartenterminal: Fehlercode 4044.
    (3) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 106: TAB_KON_216 Fehlercodes TUC_KON_200 „SendeAPDU“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4044
    Technical
    Error
    Fehler beim Zugriff auf das Kartenterminal
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4232
    Technical
    Error
    der Aufrufer besitzt nicht das Karten-Lock

    <=

    4.1.5.4.22 TUC_KON_024 „Karte zurücksetzen“

    TIP1-A_4584

    Der Konnektor MUSS den technischen Use Case „Karte zurücksetzen“ gemäß TUC_KON_024 umsetzen.

    Tabelle 107: TAB_KON_737 – TUC_KON_024 „Karte zurücksetzen“

    Element
    Beschreibung
    Name
    TUC_KON_024 „Karte zurücksetzen“
    Beschreibung
    Der technische Use Case setzt die gewählte Karte zurück (alle erreichten Sicherheitszustände werden auf der Karte und in der Verwaltung des Konnektors zurückgesetzt; auf der Karte wird MF selektiert). Ein eventuell laufendes C2C wird dabei abgebrochen.
    Auslöser
    Fachmodul
    Vorbedingungen
    keine
    Eingangsdaten
    • ctId – optional/verpflichtend, wenn keine cardSession angegeben ist
      (Kartenterminalidentifikator)

    • slotId – optional/verpflichtend, wenn keine cardSession angegeben ist
      (Nummer des Slots, in dem die Karte steckt)
    • cardSession – optional/verpflichtend, wenn ctId und slotId nicht angegeben sind
      (Angabe der CardSession alternativ zur Angabe von ctId und slotId)

    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
    1.      Wenn cardSession gegeben, dann ermittle ctId und slotId
    2.      Der Konnektor prüft, dass entweder die Karte nicht reserviert ist oder der Aufrufer im Besitz des Karten-Locks ist.
    3.      Brich eventuell parallel laufenden TUC_KON_005 ab
    4.      Sende SICCT RESET ICC für slotId an das Kartenterminal CtID, um einen Warm Reset auszulösen
    5.      Lösche alle Sicherheitszustände aus CARDSESSION.AUTHSTATE und den Inhalt von CARDSESSION.AUTHBY.
    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Der Aufrufer ist nicht im Besitz des Karten-Locks, Fehlercode 4232
    (4) Karte antwortet mit einer spezifischen Fehlermeldung, Fehlercode <Kartenfehlercode gemäß [gemSpec_COS]>
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 108: TAB_KON_544 Fehlercodes TUC_KON_024 „Karte zurücksetzen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4232
    Technical
    Error
    der Aufrufer ist nicht im Besitz des Karten-Locks

    <=

    4.1.5.4.23 TUC_KON_216 „LeseZertifikat“

    TIP1-A_4585

    Der Konnektor MUSS den technischen Use Case „LeseZertifikat“ gemäß TUC_KON_216 umsetzen.

    Tabelle 109: TAB_KON_230 – TUC_KON_216 „LeseZertifikat“

    Element
    Beschreibung
    Name TUC_KON_216 „LeseZertifikat“
    Beschreibung Dieser Use Case beschreibt das Lesen eines Zertifikates von einer Karte
    Auslöser
    • Aufruf der Operation ReadCardCertificate des Zertifikatsdienstes durch das Clientsystem.
    • Aufruf durch Fachmodul
    • Aufruf im Rahmen von technischen Use Cases der Basisdienste des Konnektors
    Vorbedingungen Keine
    Eingangsdaten
    • cardSession
    • fileIdentifier – optional/verpflichtend, wenn kein sfid angegeben ist
      (FID der zu lesenden Datei)
    • sfid– optional/verpflichtend, wenn kein fileIdentifier angegeben ist
      (Short File Identifier der zu lesenden Datei)
    • folder
      (Verzeichnis/Applikation auf der Karte, in dem sich das Zertifikat befindet)
    Komponenten Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    • certificate
      (gelesenes Zertifikat)
    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(cardSession)
    2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer das Karten-Lock besitzt.
    3. Prüfe CARDSESSION.AUTHSTATE für adressierte Datei wie in Zugriffsbedingung der Karte definiert vorhanden
    4. Rufe TUC_KON_202 „LeseDatei“ {
          cardSession;
          fileIdentifier;
          folder }
      oder TUC_KON_202 „LeseDatei“ {
          cardSession;
          sfid;
          folder }
    5. Das Zertifikat wird an den Aufrufer zurückgegeben.
    Varianten/
    Alternativen
    Keine
    Fehlerfälle (2) Karte ist fremd reserviert, Fehlercode 4093
    (->4) Es wurde versucht, ein Zertifikat von der Karte zu lesen, welches auf der Karte nicht vorhanden ist (Fehlercode 4256). Hierbei kann es sich um ein fehlendes Zertifikatsobjekt (z.B. adressiertes ECC-Zertifikat auf HBA G2.0) oder ein leeres Zertifikatsobjekt (z.B. adressiertes ECC-Zertifikat auf gSMC-K G2.0, welches aber nicht personalisiert wurde) handeln.
    Nichtfunktionale Anforderungen Keine
    Zugehörige Diagramme Keine

    Tabelle 110: TAB_KON_209 Fehlercodes TUC_KON_216 „LeseZertifikat“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4256 Technical Warning Zertifikat auf Karte nicht vorhanden

    <=

    4.1.5.4.24 TUC_KON_036 „LiefereFachlicheRolle“

    TIP1-A_5478

    Der Konnektor MUSS den technischen Use Case TUC_KON_036 „LiefereFachlicheRolle” umsetzen.

    Tabelle 111: TAB_KON_827 TUC_KON_036 „LiefereFachlicheRolle“

    Element
    Beschreibung
    Name
    TUC_KON_036 „LiefereFachlicheRolle“
    Beschreibung
    Dieser TUC liefert die fachliche Rolle, die der OID aus dem X.509Zertifikat der gesteckten Karte zugeordnet ist.
    Es werden nur folgende Karten unterstützt:
    HBAx, SM-B, EGK, KVK

    Es werden nur die AUT-Zertifikate ausgelesen.
    Für eine Karte ab der Generation G2.1 wird das AUT-Zertifikat (ECC) geprüft.
    Für eine Karte der Generation G2.0 wird das AUT-Zertifikat (RSA) geprüft.

    Auslöser
    • Aufruf durch ein Fachmodul oder eine Basisanwendung des Konnektors
    Vorbedingungen
    Keine
    Eingangsdaten
    • cardSession
    Komponenten
    Konnektor, Karte
    Ausgangsdaten
    • role
      (fachliche Rolle gemäß [gemSpec_PKI#Tab_PKI_254 Zugriffsprofile für eine Rollenauthentisierung]

    Nachbedingungen
    Keine
    Standardablauf
    1. Ermittle Card = CM_CARD_LIST(cardSession)
    2. Prüfe, dass der Karte entweder kein Lock zugeordnet ist oder der Aufrufer im Besitz des Karten-Locks ist.
    3. Wenn CARD.TYPE = KVK, dann setze fachliche Rolle = „Versicherter“ und springe zu Schritt 8.
    4. Ermittle fileIdentifier und folder des C.AUT-Zertifikates unter Berücksichtigung des kryptographischen Algorithmus crypt für die Karte, die durch die cardSession referenziert wird.
      Für eine Karte ab der Generation G2.1 setze crypt=ECC.
      Für eine Karte der Generation G2.0 setze crypt=RSA.
      Welches Zertifikat gelesen wird, ist in TAB_KON_858 beschrieben.

    5. Lies Zertifikat:
      Rufe TUC_KON_216 "LeseZertifikat" {
          cardSession;
          
      fileIdentifier = fileIdentifier (AUT-Zertifikat);
          folder = folder(AUT-Zertifikat)}

    6. Ermittle ProfessionOIDs aus Extension Admission des Zertifikates: Rufe TUC_PKI_009 „Rollenermittlung” {certificate}
    7. Ermittle die fachliche Rolle, die den ProfessionOIDs entspricht,
      gemäß [gemSpec_PKI# Tab_PKI_254 Zugriffsprofile für eine Rollenauthentisierung].

    8. Rückgabe $role (fachliche Rolle) an den Aufrufer
    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    * Karte antwortet nicht innerhalb von CARD_TIMEOUT_CARD Sekunden, Fehlercode 4094
    (2) Karte ist fremd reserviert, Fehlercode 4093
    (7) ProfessionOIDs mappen nicht auf die gleiche Rolle, Fehlercode 4210
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 112: TAB_KON_829 Fehlercodes TUC_KON_036 „LiefereFachlicheRolle“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4093
    Technical
    Error
    Karte wird in einer anderen Kartensitzung exklusiv verwendet
    4094
    Technical
    Error
    Timeout beim Kartenzugriff aufgetreten
    4210
    Technical
    Error
    ProfessionOIDs nicht eindeutig auf eine Rolle abbildbar

    <=

    4.1.5.5 Operationen an der Außenschnittstelle

    TIP1-A_4586-03

    Der Konnektor MUSS für Clients eine Basisanwendung Kartendienst mit den Operationen VerifyPin, ChangePin, UnblockPin, GetPinStatus an der Außenschnittstelle anbieten.

    Tabelle 113: TAB_KON_038 Basisanwendung Karten- und Kartenterminaldienst

    Name
    CardService
    Version (KDV)
    8.1.0 (WSDL- und XSD-Version)
    8.1.1 (WSDL- und XSD-Version)
    8.1.2 (WSDL-Version) 8.1.3 (XSD-Version)

    Namensraum
    Siehe GitHub
    Namensraum-Kürzel
    CARD für Schema und CARDW für WSDL
    Operationen
    Name
    Kurzbeschreibung
    VerifyPin
    PIN prüfen
    ChangePin
    PIN ändern
    UnblockPin
    PIN entsperren
    GetPinStatus
    PIN-Status ermitteln
    EnablePin
    Erfordernis der PIN-Verifikation einschalten
    DisablePin
    Erfordernis der PIN-Verifikation abschalten
    WSDL
    CardService.wsdl (WSDL-Version 8.1.0)
    CardService_v8_1_1.wsdl
    CardService_v8_1_2.wsdl

    Schema
    CardService.xsd (XSD-Version 8.1.0)
    CardService_v8_1_1.xsd
    CardService_v8_1_3.xsd


    <=

    4.1.5.5.1 VerifyPin

    TIP1-A_4587

    Der Konnektor MUSS an der Außenschnittstelle eine Operation VerifyPin, wie in Tabelle TAB_KON_047 Operation VerifyPin beschrieben, anbieten.

    Tabelle 114: TAB_KON_047 Operation VerifyPin

    Name
    VerifyPin
    Beschreibung
    Stößt die sichere Eingabe einer PIN am PIN-Pad des Kartenterminals für eine Karte an.
    Das Ergebnis der PIN-Prüfung gibt Auskunft darüber, ob die PIN richtig oder falsch war oder aufgrund zu vieler Fehlversuche blockiert ist.
    Eine Karte kann potentiell mehrere PINs haben. Insbesondere für die qualifizierte elektronische Signatur existiert eine separate PIN. Diese PIN darf nur über das PIN-Pad eingegeben werden.
    Die PIN-Verifikation und die damit verbundene Änderung des Sicherheitsstatus der Karte erfolgt nur für die durch den Aufrufkontext adressierte Kartensitzung. Falls die Karte in einem zentralen Kartenterminal steckt, auf das der Arbeitsplatz Zugriff hat, erfolgt eine Remote-PIN-Eingabe. Das Kartenterminal für die PIN-Eingabe ergibt sich dabei aus der im Aufrufkontext angegebenen Mandanten-ID und Arbeitsplatz-ID
    Diese Operation entspricht dem Aufruf von TUC_KON_012 „PIN verifizieren“. Dort sind auch die Display Messages definiert, die bei PIN-Eingabe am Kartenterminal anzuzeigen sind (TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal). Die beim Aufruf von TUC_KON_012 anzugebende PIN-Art lautet „mandatorisch“. Die PIN-Verifikation wird also unabhängig vom erreichten Sicherheitsstatus in der Karte immer durchgeführt.
    Aufrufparameter



    Name
    Beschreibung
    Context
    MandantId, CsId, WorkplaceId verpflichtend; UserId verpflichtend für HBAx
    CardHandle
    Adressiert die Karte, für die die PIN verifiziert werden soll.
    Die Operation DARF die PIN-Verifikation mit der eGK NICHT unterstützen. Unterstützt werden die Kartentypen HBAx und SM-B. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
    PinTyp
    Gibt an, welche PIN der Karte verifiziert werden soll.
    Erlaubte Belegung von PinTyp in Abhängigkeit der durch Cardhandle referenzierten Karte:
    • HBAx: PIN.CH
    • SM-B: PIN.SMC
    Rückgabe

    Name
    Beschreibung
    Status
    Enthält den Ausführungsstatus der Operation (siehe 3.5.2)
    PinResult
    Wert
    Bedeutung
    OK
    Prüfung war erfolgreich
    REJECTED
    PIN war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries
    ERROR
    Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
    WASBLOCKED
    PIN war zum Aufrufzeitpunkt bereits gesperrt
    NOWBLOCKED
    PIN ist durch aktuellen Fehlversuch gesperrt
    TRANSPORT
    _PIN
    PIN ist mit Transportschutz versehen
    LeftTries
    Im Falle von Result=REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
    Vorbedingung
    Keine
    Nachbedingung
    keine
    Der Ablauf der Operation VerifyPin ist in Tabelle TAB_KON_738 Ablauf VerifyPin beschrieben.

    Tabelle 115: TAB_KON_738 Ablauf VerifyPin

    Nr.

    Aufruf Technischer
    Use Case oder
    Interne Operation

    Beschreibung

    1.



    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.



    TUC_KON_000 „Prüfe Zugriffs-berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.



    TUC_KON_026 „Liefere CardSession“

    Ermittle cardSession über TUC_KON_026 {
        mandatId =$context.mandantId;
        clientsystemId  = $context.clientsystemId;
        userId = $context.userId;
        cardHandle }

    4.



    TUC_KON_012 „PIN verifizieren“

    Verifiziere PIN über TUC_KON_012 {
        cardSession;
        workplaceId = $context.workplaceId;
        pinRef = PinRef(PinTyp);
        appName = „” (Leerstring);
        verificationType = Mandatorisch }

    5.



    Verifikationsergebnis auswerten

    Wenn TUC_KON_012 mit Fehler 4065 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= TRANSPORT_PIN abgefangen.
    Wenn TUC_KON_012 den Returncode BLOCKED liefert, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= NOWBLOCKED zurückgegeben.
    Wenn TUC_KON_012 mit Fehler 4063 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= WASBLOCKED zurückgegeben

    Tabelle 116: TAB_KON_545 Fehlercodes „VerifyPin“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4078
    Security
    Error
    PIN-Eingabe über das Clientsystem ist nicht zugelassen
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.5.2 ChangePin

    TIP1-A_4588

    Der Konnektor MUSS an der Außenschnittstelle eine Operation ChangePin, wie in Tabelle TAB_KON_049 Operation ChangePin beschrieben, anbieten.

    Tabelle 117: TAB_KON_049 Operation ChangePin

    Name
    ChangePin
    Beschreibung
    Ändert eine PIN einer Karte. Alte und neue PIN werden dabei am PIN-Pad des Kartenterminals eingegeben.
    Falls die Karte in einem zentralen Kartenterminal steckt, auf das der im Aufrufkontext angegebene Arbeitsplatz Zugriff hat, erfolgt eine Remote-PIN-Eingabe.
    Diese Operation entspricht dem Aufruf TUC_KON_019 „PIN ändern.
    Aufrufparameter


    Name
    Beschreibung
    Context
    MandantId, CsId, WorkplaceId verpflichtend; UserId optional (verpflichtend beim HBA)
    CardHandle
    Adressiert die Karte, für die die PIN geändert werden soll. Unterstützt werden die Kartentypen EGK, HBAx und SM-B. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
    PinTyp
    Gibt an, welche PIN der Karte geändert werden soll.
    Erlaubte Belegung von PinTyp in Abhängigkeit der durch CardHandle referenzierten Karte:
    • eGK G1+: PIN.CH,
    • eGK G2: PIN.CH,  
      MRPIN.NFD, MRPIN.NFD_READ, MRPIN.DPE, MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS, PIN.AMTS_REP
    • zusätzlich eGK G2.0: MRPIN.DPE_READ
    • HBAx: PIN.CH, PIN.QES
    • SM-B: PIN.SMC
    Rückgabe



    Name
    Beschreibung
    LeftTries
    Im Falle von REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
    Status
    Enthält den Ausführungsstatus der Operation, siehe 3.5.2


    PinResult
    Wert
    Bedeutung
    OK
    PIN-Änderung war erfolgreich
    ERROR
    Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
    REJECTED
    OldPIN war falsch Die Anzahl der verbleibenden Versuche ist im Element LeftTries
    WASBLOCKED
    PIN war zum Aufrufzeitpunkt bereits gesperrt
    NOWBLOCKED
    PIN ist durch aktuellen Fehlversuch gesperrt
    Vorbedingung
    Keine
    Nachbedingung
    keine

    Tabelle 118: TAB_KON_546 Ablauf ChangePin

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.


    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.


    TUC_KON_000 „Prüfe Zugriffs-berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.


    TUC_KON_026 „Liefere CardSession“

    Ermittle cardSession über TUC_KON_026 {
        mandantId =$context.mandantId;
        clientsystemId  = $context.clientsystemId;
        cardHandle;
        userId = $context.userId }

    4.


    TUC_KON_019 „PIN ändern“

    Ändere PIN über TUC_KON_019 {
        cardSession;
        workplaceId = $context.workplaceId;
        pinRef = PinRef(PinTyp) }

    5.


    Verifikationsergebnis auswerten

    Wenn TUC_KON_019 den Returncode BLOCKED liefert, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= NOWBLOCKED zurückgegeben.
    Wenn TUC_KON_019 mit Fehler 4063 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= WASBLOCKED zurückgegeben.

    Tabelle 119: TAB_KON_547 Fehlercodes „ChangePin“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4072
    Technical
    Error
    Ungültige PIN-Referenz PinRef
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.5.3 GetPinStatus

    TIP1-A_4589

    Der Konnektor MUSS an der Außenschnittstelle eine Operation GetPinStatus, wie in Tabelle TAB_KON_051 Operation GetPinStatus beschrieben, anbieten.

    Tabelle 120: TAB_KON_051 Operation GetPinStatus

    Name
    GetPinStatus
    Beschreibung
    Diese Operation gibt Auskunft über den PIN-Zustand einer Karte.
    Für transportgeschützte PIN gibt die Operation die Art des Transportschutzes an.
    Für Echt-PINs kann mit dieser Operation die Anzahl der noch verbleibenden Versuche für PIN-Verifikationen ermittelt werden oder ob die PIN bereits verifiziert wurde.
    Aufruf-parameter


    Name
    Beschreibung
    Context
    MandantId, CsId, WorkplaceId; UserId
    CardHandle
    Adressiert die Karte, für die der PIN-Status ermittelt werden soll. Unterstützt werden die Kartentypen EGK, HBAx und SM-B. Eine KVK ist nicht zulässig. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
    PinTyp
    Gibt an, für welche PIN der Karte der PIN-Status ermittelt werden soll.
    Erlaubte Belegung von PinTyp in Abhängigkeit der durch Cardhandle referenzierten Karte:
    • eGK G1+: PIN.CH
    • eGK G2: PIN.CH,
      MRPIN.NFD, MRPIN.NFD_READ, MRPIN.DPE,  MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS, PIN.AMTS_REP
    • zusätzlich eGK G2.0: MRPIN.DPE_READ
    • HBAx: PIN.CH, PIN.QES
    • SM-B: PIN.SMC
    Rückgabe



    Name
    Beschreibung
    Status
    Enthält den Ausführungsstatus der Operation siehe 3.5.2
    PinStatus
    Status der PIN. Die folgenden Werte sind verpflichtend:
    Wert
    Bedeutung
    VERIFIED
    Bereits verifiziert (in CARDSESSION.AUTHSTATE vorhanden)
    TRANSPORT_PIN
    Transport-PIN
    EMPTY_PIN
    Leer-PIN
    BLOCKED
    gesperrt
    VERIFIABLE
    Echt-PIN, noch nicht verifiziert
    DISABLED
    PIN-Schutz ausgeschaltet (Verifikation nicht erforderlich)
    LeftTries
    Bei einer Echt-PIN wird hier bei PinStatus = VERIFIABLE die Anzahl der verbleibenden möglichen Versuche für die Verifikation der PIN zurückgegeben, bei einer gesperrten PIN 0.
    Vorbedingung
    keine
    Nachbe-dingung
    keine

    Tabelle 121: TAB_KON_548 Ablauf GetPinStatus

    Nr .

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.



    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.



    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;  // falls angegeben
        cardHandle }
    Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.

    3.



    TUC_KON_026 „Liefere CardSession“

    Ermittle cardSession über TUC_KON_026 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        userId = $context.userId;  // falls angegeben ;
        cardHandle }

    4.



    TUC_KON_022 „Liefere PIN-Status“

    Ermittle PinStatus über TUC_KON_022 {
        cardSession;
        pinRef = PinRef(PinTyp) }

    Tabelle 122: TAB_KON_549 Fehlercodes „GetPinStatus“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4001
    Technical
    Error
    interner Fehler
    4072
    Technical
    Error
    ungültige PIN-Referenz PinRef
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.5.4 UnblockPin

    TIP1-A_4590

    Der Konnektor MUSS an der Außenschnittstelle eine Operation UnblockPin, wie in Tabelle TAB_KON_053 Operation UnblockPin beschrieben, anbieten.

    Tabelle 123: TAB_KON_053 Operation UnblockPin

    Name
    UnblockPin
    Beschreibung
    Mit diesem Kommando kann eine blockierte PIN wieder freigeschaltet werden. Dabei wird der Wiederholungszähler für diese PIN in der Karte auf seinen Anfangswert zurückgesetzt und es KANN eine neue PIN gesetzt werden. Um diese Aktion durchführen zu können, muss eine PUK (auch als Resetting Code bezeichnet) präsentiert werden.
    PIN und PUK werden am PIN-Pad des Kartenterminals eingegeben.
    Falls die Karte in einem zentralen Kartenterminal steckt, auf das der im Aufrufkontext angegebene Arbeitsplatz Zugriff hat, erfolgt eine Remote-PIN-Eingabe. Das Kartenterminal für die PIN-Eingabe ergibt sich dabei aus der im Aufrufkontext angegebenen Mandanten-ID und Arbeitsplatz-ID.
    Diese Operation entspricht dem Aufruf von TUC_KON_021 „PIN entsperren“.
    Aufruf-parameter


    Name
    Beschreibung
    Context
    MandantId, CsId, WorkplaceId verpflichtend; UserId (optional, für HBA verpflichtend)
    CardHandle
    Adressiert die Karte, für die die Blockierung der PIN aufgehoben werden soll. Unterstützt werden die Kartentypen EGK, HBAx und SM-B. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4209 abbrechen.
    PinTyp
    Gibt an, für welche PIN der Karte die Blockierung aufgehoben werden soll.
    Erlaubte Belegung von PinTyp in Abhängigkeit der durch Cardhandle referenzierten Karte:
      -   eGK G1+: PIN.CH
     -   eGK G2: PIN.CH,  MRPIN.NFD, MRPIN.NFD_READ,
        MRPIN.DPE, MRPIN.GDD, MRPIN.OSE, MRPIN.AMTS,
       PIN.AMTS_REP
       - zusätzlich eGK G2.0: MRPIN.DPE_READ
     -    HBAx: PIN.CH, PIN.QES
     -    SM-B: PIN.SMC

    SetNewPin
    Dieses Flag zeigt an, ob eine neue PIN gesetzt werden soll. Wird dieses Flag nicht angegeben, so wird FALSE angenommen.
    Das Flag ist notwendig, um bei Eingabe am PIN-Pad eindeutig festzulegen, ob eine neue PIN gesetzt werden soll.
    Rückgabe



    Name
    Beschreibung
    LeftTries
    Im Falle von REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche für die Eingabe der PUK zurückgegeben.
    Status
    Enthält den Ausführungsstatus der Operation siehe 3.5.2
    PinResult
    Wert
    Bedeutung
    OK
    Prüfung war erfolgreich.
    ERROR
    Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error.
    REJECTED
    PUK war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries.
    WASBLOCKED
    PUK war zum Aufrufzeitpunkt bereits gesperrt
    NOWBLOCKED
    PUK ist durch aktuellen Fehlversuch gesperrt
    Vorbe-dingungen
    keine
    Nachbe-dingungen
    keine

    Tabelle 124: TAB_KON_550 Ablauf UnblockPIN

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.


    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.



    TUC_KON_000 „Prüfe Zugriffs-berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId; // falls angegeben
        cardHandle }

    3.



    TUC_KON_026 „Liefere CardSession“

    Ermittle cardSession über TUC_KON_026
    {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        userId = $context.userId;  // falls angegeben
        cardHandle }

    4.



    TUC_KON_021 „PIN entsperren“

    Rücksetzen des Fehlbedienungszählers über TUC_KON_021 {
        cardSession;
        workplaceId = $context.workplaceId;
        pinRef = pinRef(PinTyp);
        setNewPIN = SetNewPIN }

    5.



    Verifikationsergebnis auswerten

    Wenn TUC_KON_021 den Returncode BLOCKED liefert, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= NOWBLOCKED zurückgegeben.
    Wenn TUC_KON_021 mit dem Fehlercode 4064 abbricht, wird dies als erfolgreicher Operationsdurchlauf mit PinResult= WASBLOCKED zurückgegeben.

    Tabelle 125: TAB_KON_551 Fehlercodes „UnblockPin“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.5.5 EnablePin

    TIP1-A_5487

    Der Konnektor MUSS an der Außenschnittstelle eine Operation EnablePin, wie in Tabelle TAB_KON_242 Operation EnablePin beschrieben, anbieten.

    Tabelle 126: TAB_KON_242 Operation EnablePin

    Name
    EnablePin
    Beschreibung
    Schaltet für eine Multireferenz-PIN das Erfordernis, das Nutzergeheimnis zu verifizieren, ein, so dass der Sicherheitszustand nur durch eine erfolgreiche Benutzerverifikation gesetzt werden kann.
    Aufrufparameter



    Name
    Beschreibung
    Context
    MandantId, ClientSystemId, WorkplaceId verpflichtend;
    CardHandle
    Adressiert die Karte, deren MRPIN bearbeitet werden soll. Es werden nur eGKs ab Generation 2 unterstützt.
    PinTyp
    Gibt an, auf welche MRPIN der Karte die Operation angewendet werden soll.
    Erlaubte Werte:
    • eGK G2: MRPIN.NFD, MRPIN.DPE, MRPIN.GDD
    • zusätzlich ab eGK G2.1: MRPIN.AMTS
    Rückgabe



    Name
    Beschreibung
    Status
    Enthält den Ausführungsstatus der Operation, siehe 3.5.2
    PinResult
    Wert
    Bedeutung
    OK
    Aktivierung war erfolgreich
    REJECTED
    PIN war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries
    ERROR
    Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
    WASBLOCKED
    PIN war zum Aufrufzeitpunkt bereits gesperrt
    NOWBLOCKED
    PIN ist durch aktuellen Fehlversuch gesperrt
    TRANSPORT_PIN
    Dieser Wert wird nicht verwendet
    LeftTries
    Im Falle von Result=REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
    Vorbedingung
    keine
    Nachbedingung
    Für das Erreichen des Sicherheitszustands der MRPIN ist eine Nutzereingabe erforderlich


    Tabelle 127: TAB_KON_243 Ablauf EnablePin

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.


    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.


    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle }
    Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.

    3.


    TUC_KON_026 „Liefere CardSession“

    Ermittle cardSession über TUC_KON_026 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        userId = $context.userId;
        cardHandle }

    4.


    TUC_KON_027 „PIN-Schutz ein-/ausschalten“

    Aktiviere das Erfordernis der Benutzerverifikation der MRPIN durch Aufruf des TUC_KON_027 „PIN-Schutz ein-/ausschalten“ {
        cardSession;
        pinRef  =   PinRef(PinType);
        enable = true}

    5.


    Verifikationsergebnis auswerten

    Als erfolgreicher Operationsdurchlauf wird nur PinResult=OK gewertet.
    Alle anderen Resultate sind Fehlerfälle, und neben dem Status ist auch PinResult entsprechend zu setzen. Dabei gelten folgende Regeln:
    Wenn TUC_KON_027 den PIN-Status BLOCKED liefert, wird auf PinResult=NOWBLOCKED abgebildet.
    Wenn TUC_KON_027 mit Fehler 4063 abbricht, wird dies auf PinResult=WASBLOCKED abgebildet.


    Tabelle 128: TAB_KON_244 Fehlercodes „EnablePin“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4072
    Technical
    Error
    Ungültige PIN-Referenz PinRef
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.5.6 DisablePin

    TIP1-A_5488

    Der Konnektor MUSS an der Außenschnittstelle eine Operation DisablePin, wie in Tabelle TAB_KON_245 Operation DisablePin beschrieben, anbieten.

    Tabelle 129: TAB_KON_245 Operation DisablePin

    Name
    DisablePin
    Beschreibung
    Schaltet für eine Multireferenz-PIN das Erfordernis, das Nutzergeheimnis zu verifizieren, ab. Die MRPIN verhält sich danach bei allen Zugriffen auf die durch sie geschützten Objekte, als wäre sie freigeschaltet.
    Aufrufparameter



    Name
    Beschreibung
    Context
    MandantId, ClientSystemId, WorkplaceId verpflichtend;
    CardHandle
    Adressiert die Karte, deren MRPIN bearbeitet werden soll. Es werden nur eGKs ab Generation 2 unterstützt.
    PinTyp
    Gibt an, auf welche MRPIN der Karte die Operation angewendet werden soll.
    Erlaubte Werte:
    • eGK G2: MRPIN.NFD, MRPIN.DPE, MRPIN.GDD
    • zusätzlich ab eGK G2.1: MRPIN.AMTS
    Rückgabe



    Name
    Beschreibung
    Status
    Enthält den Ausführungsstatus der Operation siehe 3.5.2
    PinResult
    Wert
    Bedeutung
    OK
    Aktivierung war erfolgreich
    REJECTED
    PIN war falsch. Die Anzahl der verbleibenden Versuche ist im Element LeftTries
    ERROR
    Ein Bearbeitungsfehler ist aufgetreten. Fehlerursache im Feld Error
    WASBLOCKED
    PIN war zum Aufrufzeitpunkt bereits gesperrt
    NOWBLOCKED
    PIN ist durch aktuellen Fehlversuch gesperrt
    TRANSPORT_PIN
    Dieser Wert wird nicht verwendet
    LeftTries
    Im Falle von Result=REJECTED wird hier die Anzahl der verbleibenden möglichen Versuche zurückgegeben.
    Vorbedingung
    keine
    Nachbedingung
    Der Sicherheitszustand der PIN ist dauerhaft (bis zur expliten Aktivierung mit EnablePin) gesetzt, ohne dass eine Nutzereingabe erforderlich wäre

    Tabelle 130: TAB_KON_246 Ablauf DisablePin

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.


    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.



    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle }
    Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.

    3.



    TUC_KON_026 „Liefere CardSession“

    Ermittle cardSession über TUC_KON_026 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientSystemId;
        userId = $context.userId;
        cardHandle }

    4.



    TUC_KON_027 „PIN-Schutz ein-/ausschalten“

    Deaktiviere das Erfordernis der Benutzerverifikation der MRPIN durch Aufruf des TUC_KON_027 „PIN-Schutz ein-/ausschalten“ {
        cardSession;
        pinRef  =   PinRef(PinType);
        enable = false}

    5.



    Verifikations-ergebnis auswerten

    Als erfolgreicher Operationsdurchlauf wird nur PinResult=OK gewertet.
    Alle anderen Resultate sind Fehlerfälle, und neben dem Status ist auch PinResult entsprechend zu setzen. Dabei gelten folgende Regeln:
    Wenn TUC_KON_027 den PIN-Status BLOCKED liefert, wird auf PinResult=NOWBLOCKED abgebildet.
    Wenn TUC_KON_027 mit Fehler 4063 abbricht, wird dies auf PinResult=WASBLOCKED abgebildet.


    Tabelle 131: TAB_KON_247 Fehlercodes „DisablePin“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4072
    Technical
    Error
    ungültige PIN-Referenz PinRef
    4209
    Technical
    Error
    Kartentyp %CardType% wird durch diese Operation nicht unterstützt.


    <=

    4.1.5.6 Betriebsaspekte

    TIP1-A_4592

    Der Konnektor MUSS es einem Administrator ermöglichen, Konfigurationsänderungen gemäß Tabelle TAB_KON_554 vorzunehmen.

    Tabelle 132: TAB_KON_554 Konfiguration des Kartendienstes

    ReferenzID
    Belegung
    Bedeutung
    CARD_TIMEOUT_CARD
    Sekunden
    Maximale Zeit, die ein Aufruf einer Kartenoperation dauern darf, bevor der Aufruf abgebrochen wird.
    Der Konnektor MUSS sicherstellen, dass dieser Parameter einen Wert besitzt, mit dem ein reibungsloser Betrieb gewährleistet ist, und MUSS dem Administrator die Möglichkeit bieten, diesen Parameter zu konfigurieren.

    <=

    4.1.5.6.1 TUC_KON_025 "Initialisierung Kartendienst"

    TIP1-A_4593

    Der Konnektor MUSS den technischen Use Case „Initialisierung Kartendienst“ gemäß TUC_KON_025 umsetzen.

    Tabelle 133: TAB_KON_555 - TUC_KON_025 „Initialisierung Kartendienst“

    Element
    Beschreibung
    Name
    TUC_KON_025 „Initialisierung Kartendienst“
    Beschreibung
    Nach dem Start des Kartendienstes MUSS der Konnektor für alle gesteckten Karten den TUC_KON_001 {ctId, slotId } aufrufen und CM_CARD_LIST befüllen.
    Auslöser
    der Kartendienst wird gestartet
    Vorbedingungen
    Kartenterminaldienst wurde gestartet
    Eingangsdaten
    CTM_CT_LIST
    Komponenten
    Karte, Kartenterminal, Konnektor
    Ausgangsdaten
    Aktuelle CM_CARD_LIST
    Standardablauf
    1. Rufe TUC_KON_001 „Karte öffnen“
    2. Wiederhole, bis für alle gesteckten Karten ein Eintrag in CM_CARD_LIST existiert.
    Varianten/Alternativen
    keine
    Fehlerfälle
    keine
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    <=

    4.1.5.6.2 Kartenübersicht und PIN-Management

    TIP1-A_5110

    Die Administrationsoberfläche MUSS dem Administrator eine Übersichtsseite anbieten, die alle in CM_CARD_LIST enthaltenen Karten listet.
    In dieser Übersichtsseite muss zu jeder Karte dargestellt werden:

    Ferner MÜSSEN auf Verlangen des Administrators zu jeder Karte neben den obigen Informationen auch folgende Details angezeigt werden:
    <=

    TIP1-A_5111

    Über die Administrationsoberfläche MUSS der Administrator für jede in der Übersichtsseite angezeigte Karte vom Typ SM-B die folgenden TUCs für die PIN.SMC auslösen können.
    Für diese MUSS er einen der gemäß Kapitel 4.1.1.6 [TIP1-A_4526] definierten Mandanten auswählen können:

    Die Eingabe der PIN SOLL von jedem vom Informationsmodell her zulässigen Kartenterminal aus möglich sein.
    <=

    Der Konnektor kann den Administrator zur Laufzeit entscheiden lassen, an welchem Kartenterminal die PIN eingegeben werden soll, indem er ihn wählen lässt, ob er die PIN am Kartenterminal eingibt, in dem die betroffene SM-B steckt, oder ihn den Arbeitsplatz wählen lässt, von dem aus er die Remote-PIN eingibt.

    4.1.6 Systeminformationsdienst

    Der Systeminformationsdienst stellt Basisdiensten, Fachmodulen und Clientsystemen sowohl aktiv (Push-Mechanismus) wie passiv (Pull-Mechanismus) Informationen zur Verfügung. Dabei erhebt er selbst keine Daten, sondern dient nur als zentraler Mechanismus, der von anderen Basisdiensten und Fachmodulen zur Verteilung und Bereitstellung derer Informationen verwendet werden kann.

    Innerhalb des Systeminformationsdienstes werden folgende Präfixe für Bezeichner verwendet:

    Push-Mechanismus

    Der Push-Mechanismus des Systeminformationsdienstes hat die Aufgabe, Ereignisse von internen Ereignisquellen im Konnektor (z. B. von anderen Basisdiensten wie Kartendienst, Kartenterminaldienst oder Fachmodulen) an alle Basisdienste und Fachmodule sowie an die bei ihm registrierten Ereignisempfänger (Clientsysteme) weiterzuleiten.

    Die Namen der Ereignisse, die Topics, sind als Baumstruktur organisiert und werden mittels „/“-getrennter Liste angegeben (z. B. „Auslöser/Ereigniskategorie1/…/Ereignis1“). Die konkreten Topics werden innerhalb der einzelnen Funktionsmerkmale kontextbezogen definiert und im Anhang in einer zentralen Liste übersichtlich dargestellt.

    Clientsysteme können sich für den Empfang bestimmter Ereigniskategorien (Topics) anmelden. Der Systeminformationsdienst übernimmt dementsprechend bei der Verteilung der Ereignisse auch eine Filterfunktion für die weiterzuleitenden Ereignisse.

    Die Zustellung der Ereignisse erfolgt unidirektional über eine Netzschnittstelle, deren Kommunikationsendpunkt („Ereignissenke“) vom Clientsystem realisiert werden muss. Zur Übertragung der Daten wird ein konnektoreigenes Protokoll cetp (Connector Event Transport Protocol) verwendet.

    Pull-Mechanismus

    Der Pull-Mechanismus des Systeminformationsdienstes hat die Aufgabe sowohl Zustandswerte als auch statische Informationen des Konnektors selbst als auch von den über ihn verwalteten Ressourcen durch Fachmodule und Clientsysteme abrufbar zu machen. Dabei können entweder Listen von Ressourcen oder Details zu einzelnen Ressourcen abgerufen werden.

    Die folgenden Unterkapitel regeln:

    4.1.6.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4594

    Der Konnektors MUSS zur Übertragung von Ereignissen eine cetp-Verbindung zu der Ereignissenke des Clientsystems aufbauen, die das Clientsystem beim Operationsaufruf Subscribe per EventTo angegeben hatte.

    <=

    TIP1-A_5536

    Der Konnektor MUSS das Anwendungsprotokoll cetp (Connector Event Transport Protocol) ausschließlich über das Transportprotokoll TCP (gebenenfalls TLS gesichert) anbieten.

    <=

    TIP1-A_4595

    Der Konnektor MUSS zur Übertragung der Ereignisse eine gesicherte Verbindung (TLS) verwenden, die vom Konnektor als TLS-Client initiiert wurde, wenn ANCL_TLS_MANDATORY=Enabled.
    Der Konnektor muss sich beim Aufbau der TLS-Sitzung gegenüber dem Clientsystem authentisieren, wenn dieses eine Authentisierung im Rahmen des TLS-Handshakes anfordert.
    Die Schalter ANCL_CAUT_MODE und ANCL_CAUT_MANDATORY wirken für die Übertragung der Ereignisse nicht.
    <=

    Für die Übermittlung der Ereignisse wurde ein leichtgewichtiges Protokoll gewählt, da vom Clientsystem keine Antwort auf Anwendungsebene erwartet wird.

    TIP1-A_4596

    Der Konnektors MUSS Ereignisse an Ereignissenken mittels Nachrichten verteilen, die gemäß TAB_KON_030 „Ereignisnachricht“ aufgebaut sind. Der Konnektor MUSS die Nachrichten mit der Zeichenkette „CETP“ beginnen, gefolgt von der Länge der folgenden Ereignisnachricht in Anzahl Bytes. Das vier Byte lange Längenfeld MUSS in der Byte-Reihenfolge Big-Endian codiert werden (das hochwertigste Byte wird als erstes übertragen).


    Abbildung 11: PIC_KON_022 Grundsätzlicher Aufbau der Ereignisnachricht

    Tabelle 134: TAB_KON_030 Ereignisnachricht

    Beschreibung

    Die Ereignisnachricht, die zur Ereignissenke gesendet wird, ist ein XML-Dokument. Die Ereignisnachricht wird in den „Umschlag“ Event gepackt.
    Wenn ein mandantenfähiges Clientsystem mehrere Anwendungskonnektoren verwendet, dann kann es die erhaltenen Ereignisbenachrichtigungen anhand der Subscription-ID einem Mandanten zuordnen.


    Topic

    Topic der Ereignisnachricht

    Type

    Typ der Ereignisnachricht (Security, Operation, Infrastructure)

    Severity

    Schwere der Ereignisnachricht (Info, Warning, Error, Fatal)

    SubscriptionID

    Identifikator der Anmeldung, der vom Konnektor bei der Operation Subscribe für die Anmeldung des jeweiligen Clientsystems vergeben wurde.

    Message

    Dieses Element enthält die Ereignisnachricht. Der Inhalt ist abhängig vom Topic und wird mittels „Key-Value“-Parametern übertragen.


    Message/Parameter/Key

    Name des Parameters (String), case sensitiv


    Message/Parameter/Value

    Wert des Parameters (String)

    Hinweise

    Das XML-Dokument MUSS UTF-8-codiert sein.


    ​​

    <=

    4.1.6.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.1.6.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.1.6.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.6.4.1 TUC_KON_256 „Systemereignis absetzen“

    TIP1-A_4598-02

    Der Konnektor MUSS für den PUSH-Mechanismus des Systeminformationsdienstes den technischen Use Case TUC_KON_256 „Systemereignis absetzen” umsetzen.

    Tabelle 135: TAB_KON_556 - TUC_KON_256 „Systemereignis absetzen“

    Element
    Beschreibung
    Name
    TUC_KON_256 „Systemereignis absetzen“
    Beschreibung
    Dieser TUC verteilt ein Ereignis im Konnektor intern (d.h. an Basisdienste und Fachmodule) sowie an Clientsysteme, die sich für den Empfang angemeldet haben (Operation Subscribe). Zusätzlich wird, bei gesetztem Flag, das Ereignis durch den Protokollierungsdienst protokolliert.
    Auslöser
    Aufruf durch Basisdienst oder Fachmodul
    Vorbedingungen
    Fall Topic = „BOOTUP/BOOTUP_COMPLETE":
    Zu allen URLs von clientseitigen Endpunkten, wie sie bei der Subscribe-Operation angegeben wurden, ist in der Subscription-Verwaltung des Konnektors eine TerminationTime gespeichert. Sie wird jeweils auf den Wert der TerminationTime der am längsten gültigen Subscription zu dem jeweiligen Endpunkt gesetzt. Die URLs von clientseitigen Endpunkten müssen bis zum Ablauf  ihrer TerminationTime auch über Bootups hinweg gespeichert werden. Vor dem Versenden des BOOTUP_COMPLETE-Events werden sämtliche Subscriptions, jedoch nicht die URLs gelöscht.  Bei Ablauf ihrer TerminationTime werden nach dem Versenden des BOOTUP_COMPLETE-Events auch die URLs gelöscht.
    Eingangsdaten
    Attribute des zu versendenden Ereignisses:
    •        topic
      (Name des Ereignisses)
    •        eventType [EventType]
          (Wenn statt eines EventType ein ErrorType übergeben wird, so wird
          der EventType daraus abgeleitet.
          Typ des Events: Op = Operation, Sec = Security, Infra = Infrastructure)
    •        severity [EventSeverity]
      (Schwere des Ereignisses: Info = Information, Warn = Warning, Err = Error, Fatal)
    •        parameters
      (weitere Parameter als key-value-Paare)
           Arbeitsanweisungen:
    •        doLog [Boolean] – optional; default = true
      (Schalter „Schreibe Protokolleintrag“)
    •        doDisp [Boolean] – optional; default = true
      (Schalter „An Clientsysteme versenden“)
    Die Bezeichnungen Op, Sec, Infra, Info, Warning, Err, Fatal werden nur in diesem Dokument verwendet und sind als Abkürzungen für die Werte Operation, Security, Infrastructure, Information, Warning, Error, Fatal in den jeweiligen Ereignisnachrichten gemäß Schema EventService.xsd zu verstehen.
    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Nachbedingungen


    Standardablauf
    Für das übergebene Ereignis werden folgende Schritte durchgeführt:
      1. Das Ereignis wird an alle Basisdienste und Fachmodule des
           Konnektors gesendet.
      2. Wenn doLog = true, erfolgt der Aufruf von TUC_KON_271 {
                 eventType = $Event.eventType
                    (mit eventType = „Op“, wenn $Event.eventType in {„Op“, „Infra“}
                     mit eventType = „Sec“, wenn $Event.eventType gleich "Sec")
                severity=$Event. severity;
                parameters= ($Event.topic, $Event.parameters) }
           Die Einschränkungen zur Protokollierung personenbezogener Daten
           gemäß TIP1-A_4710 müssen beim Aufruf von TUC_KON_271
           beachtet werden.
      3. Falls doDisp = false ist, wird an dieser Stelle abgebrochen.
      4. Das für den Versand an Clientsysteme benötigte XML-Dokument des
            Ereignisses wird aufgebaut (Element „Event“ gemäß
            EventService.XSD).
      5. Setze $subscriptionList = Liste der Clientsystem-Abonnements, die
            durch die Operationen Subscribe/Unsubscribe gepflegt werden und
            deren TerminationTime > Systemzeit.
            Im Folgenden durchläuft diese Liste der Reihe nach drei Filter. Nach
           dem letzten Filterschritt enthält $subscriptionList nur noch die
            Abonnements, an die das Ereignis versendet werden soll.
      a.             Filtern nach Topics:
            für jede $subscription in $subscriptionList {
                 wenn $event.topic nicht mit $subscription.topic beginnt
                        oder übereinstimmt (case insensitiver Vergleich),
                 dann entferne $subscription aus $subscriptionList
            }
      b.            Filtern nach Zugriffsberechtigung:
            für jede $subscription in $subscriptionList {
                  wenn TUC_KON_000 mit einem Fehler abgeschlossen
                   wird,  dann entferne $subscription aus $subscriptionList.
               Wenn CardHandle bzw. CARD_HANDLE in parameters übergeben wurde, dann
                    TUC_KON_000 {
                         mandantId = $subscription.context.mandantId;
                         clientSystemId = $subscription.context.clientsystemId;
                         workplaceId = $subscription.context.workplaceId;
                         ctId = $parameters.value
                                 für $parameters.key = „ctId“
                         cardHandle = $parameters.value
                                            für $parameters.key = [„cardHandle“ | "CARD_HANDLE"];
                         needCardSession = false;
                         allWorkplaces = false
                    }
                 oder im Fall nicht gegebenes CardHandle bzw. CARD_HANLDE
                    TUC_KON_000 {
                        mandantId = $subscription.context.mandantId;
                        clientSystemId = $subscription.context.clientsystemId;
                        workplaceId = $subscription.context.workplaceId;
                        ctId = $parameters.value
                                für $parameters.key = „ctId“
                        needCardSession = false;
                        allWorkplaces = false
                    }    }
      c.           Filtern nach XPath-Filter in Subscription ([XPATH]):
           für jede $subscription in $subscriptionList {
                wenn der XPath-Ausdruck $subscription.filter
                     angewandt auf das als XML-Dokument dargestellte
                     Ereignis
                     ein leeres Ergebnis liefert,
                dann entferne $subscription aus $subscriptionList
           }
    6. Versenden:
       für jede $subscription in $subscriptionList {
          versende das Ereignis an $subscription.eventTo
        }
    Für das versendete Ereignis wird keine Antwort durch das Clientsystem erwartet.
    Varianten/
    Alternativen
    Fall Topic = „BOOTUP/BOOTUP_COMPLETE":
    4.        Das für den Versand an Clientsysteme benötigte XML-Dokument
        des Ereignisses wird aufgebaut (Element „Event“ gemäß
        EventService.XSD, SubscriptionID als leeres Element).
    5.        Setze $urlList = Liste der URLs von clientseitigen Endpunkten, wie
        sie bei der Subscribe-Operation angegeben wurden. Clientsysteme,
        deren Subscription-URL beim Einschalten des Konnektors noch nicht
        gelöscht waren, müssen benachrichtigt werden, auch wenn dann
        bereits deren TerminationTime < Systemzeit ist.
    Versenden:
    für jede $url in $urlList {
       versende das Ereignis an $url
    }
    Für das versendete Ereignis wird keine Antwort durch das Clientsystem erwartet. Dadurch wird bei einer Nichtzustellung auch kein erneuter
    Versand des Ereignisses angestoßen, da der Konnektor keine Kenntnis
    über den Erfolg einer Ereignisübermittlung hat.
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
      (5c)    Fehler bei der Auswertung des XPath-Ausdrucks:
                    Fehlercode: 4095, nur für die jeweilige Abonnement-Prüfung.
    Fachliche Fehlermeldung
    Keine
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige
    Diagramme
    Abbildung PIC_KON_112 Aktivitätsdiagramm zu „Systemereignis absetzen“


    Abbildung 12: PIC_KON_112 Aktivitätsdiagramm zu „Systemereignis absetzen“

    Tabelle 136: TAB_KON_557 Fehlercodes TUC_KON_256 „Systemereignis absetzen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4095
    Technical
    Error
    Fehler bei der Auswertung eines XPath-Ausdruck
    <=

    4.1.6.4.2 TUC_KON_252 „Liefere KT_Liste“

    TIP1-A_4599

    Der Konnektor MUSS den technischen Use Case TUC_KON_252 „Liefere KT_Liste” umsetzen.

    Tabelle 137: TAB_KON_558 – TUC_KON_252 „Liefere KT_Liste“

    Element
    Beschreibung
    Name
    TUC_KON_252 „Liefere KT_Liste“
    Beschreibung
    Dieser TUC liefert eine Liste der Kartenterminals, die unter Beachtung der Eingangsdaten verfügbar/erreichbar sind.
    Auslöser
    Aufruf durch ein Clientsystem (Operation GetCardTerminals) oder ein Fachmodul
    Vorbedingungen
    Keine
    Eingangsdaten
      • workplaceId - optional
        (Arbeitsplatz ID)

      • clientSystemId
        (Clientystem ID)

      • mandantId
        (Mandanten ID)

    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
      • cardTerminals
        (Liste der Kartenterminals, die den angegebenen Arbeitsplätzen, Mandanten und Clientsystemen zugeordnet sind bzw. auf die diese zugreifen dürfen (siehe Zugriffsberechtigungsdienst), sowie deren aktuelle Verfügbarkeit. Verfügbarkeit bedeutet im Falle eines eHealth-Kartenterminals, dass der Konnektor eine Verbindung zum Kartenterminal aktuell hält.)

    Nachbedingungen
      • Der Zustand der Kartenterminals bleibt unverändert
    Standardablauf
    1. Erstellen der Liste aller Kartenterminals, auf die der angegebene Mandant und das angegebene Clientsystem zugreifen dürfen (siehe Zugriffsberechtigungsdienst)
      1.          Wurde der optionale Parameter workplaceId ID übergeben, so werden nur die Kartenterminals in die Liste aufgenommen, die diesem Arbeitsplatz zugeordnet sind (siehe Zugriffsberechtigungsdienst). Dazu zählen insbesondere nicht die als entfernte Kartenterminals bezeichneten KT.
      2.          Fehlt dieser Parameter, so werden alle Kartenterminals in die Liste aufgenommen, die sowohl dem Clientsystem als auch dem Mandanten zugeordnet sind.
    2. Rückgabe der Liste cardTerminals (der in Schritt 1 erstellten Liste) mit Angaben zu jedem Kartenterminal gemäß Schema „Eventservice.xsd“.
    Varianten/Alternativen
    Keine
    Fehlerfälle
    Keine
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    <=

    4.1.6.4.3 TUC_KON_253 „Liefere Karten_Liste“

    TIP1-A_4600

    Der Konnektor MUSS den technischen Use Case TUC_KON_253 „Liefere Karten_Liste” umsetzen.

    Tabelle 138: TAB_KON_559 – TUC_KON_253 „Liefere Karten_Liste“

    Element
    Beschreibung
    Name
    TUC_KON_253 „Liefere Karten_Liste“
    Beschreibung
    Dieser TUC liefert eine Liste der gesteckten Karten, die unter Beachtung der Eingangsdaten verfügbar/erreichbar sind.
    Auslöser
    Aufruf durch ein Clientsystem (Operation GetCards) oder ein Fachmodul
    Vorbedingungen
    Keine
    Eingangsanforderung
    Keine
    Eingangsdaten
      • workplaceId – optional
        (Arbeitsplatz-ID)
      • clientSystemId
        (Clientystem ID)

      • cardTerminalId - optional; verpflichtend, wenn slotId übergeben wird
        (Kartenterminalidentifikator)
      • slotId – optional
        (Nummer des Slots, beginnend bei 1)
      • mandantId
        (Mandanten ID)

      • cardType – optional
        (Kartentyp gemäß Tabelle TAB_KON_500)
    Komponenten
    Konnektor, Kartenterminal, Karte
    Ausgangsdaten
      •         cards
        (Liste der gesteckten Karten einschließlich der Informationen für CARD:card, auf die der Mandant und das Clientsystem von dem Arbeitsplatz aus zugreifen dürfen (siehe Zugriffsberechtigungsdienst)).
        Wird workplaceId nicht übergeben, so werden alle vom Clientsystem und dem Mandant erreichbaren Kartenterminals in die Liste aufgenommen. Die Eingangsdaten dienen als Filter, welche Karten in cards zurückgegeben werden.
        Beispiel: Falls cardTerminalId angegeben ist, werden nur Karten in die Liste aufgenommen, die im entsprechenden Kartenterminal stecken.)

    Nachbedingungen
      • Der Zustand der Kartenterminals und der Karten bleibt unverändert
    Standardablauf
    1. Erstellen der Liste aller Karten, auf die der angegebene Mandant und das angegebene Clientsystem zugreifen dürfen (siehe Zugriffsberechtigungsdienst).
      1.         Wurde cardTerminalId übergeben, dann nur Karten berücksichtigen, die dem dadurch referenziertem Kartenterminal zugeordnet sind.
      2.         Wurde außer cardTerminalId auch slotId übergeben, so ist nur die Karte zu berücksichtigen, die in dem angegebenen Slot steckt.
      3.         Wurde workplaceId übergeben, so werden nur die Karten in die Liste aufgenommen, auf die von diesem Arbeitsplatz aus zugegriffen werden darf (siehe „Zugriffsberechtigung Ressourcen“).
      4.         Wurde cardType übergeben, so werden nur die Karten in die Liste aufgenommen, die dem Kartentyp in CardType entsprechen.
    2. Rückgabe cards, der in Schritt 1 erstellten Liste mit Angaben zu jeder Karte gemäß Schema „Eventservice.xsd“.
    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
    (1 a)    Ungültige Kartenterminal-ID: Fehlercode: 4007
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine


    Tabelle 139: TAB_KON_560 Fehlercodes TUC_KON_253 „Liefere Karten_Liste“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4007
    Technical
    Error
    ungültige Kartenterminal-ID

    <=

    4.1.6.4.4 TUC_KON_254 „Liefere Ressourcendetails“

    TIP1-A_4602

    Der Konnektor MUSS den technischen Use Case TUC_KON_254 „Liefere Ressourcendetails” umsetzen.

    Tabelle 140: TAB_KON_561 - TUC_KON_254 „Liefere Ressourcendetails“

    Element
    Beschreibung
    Name
    TUC_KON_254 „Liefere Ressourcendetails“
    Beschreibung
    Dieser TUC liefert Detailinformationen zu einer Ressource (KT, Karte) oder dem Konnektor
    Auslöser
    Aufruf durch ein Clientsystem (Operation GetResourceInformation) oder ein Fachmodul
    Vorbedingungen
    Keine
    Eingangsanforderung
    Keine
    Eingangsdaten
      • clientSystemId
        (Clientsystem ID)

      • mandantId
        (Mandanten ID)

      • workplaceId – optional
        (Arbeitsplatz ID)

      • cardTerminalId – optional
        (Kartenterminal ID)

      • slotId – optional/zulässig nur, wenn auch cardTerminalId angegeben ist
        (Kartenslot-Nummer)

      • cardHandle – optional
      • iccsn – optional
    Komponenten
    Konnektor, Kartenterminal, Karte, HSM
    Ausgangsdaten
      • resource
        (Informationsobjekt einer Ressource (Kartenterminal, Karte, HSM))

    Nachbedingungen
      • Der Zustand der Kartenterminals, Karten und HSM bleibt unverändert
    Standardablauf
    1. Falls cardTerminalId und slotId übergeben wurde oder in den Eingangsparametern iccsn oder cardHandle enthalten ist, wird ein Informationsobjekt der Karte, die sich in dem angegebenen Slot befindet bzw. die über die Iccsn oder das CardHandle identifiziert werden kann, zurückgegeben.
    2. Falls cardTerminalId, aber keine slotId übergeben wurde, wird ein Informationsobjekt des Kartenterminals zurückgegeben.
    3. Wurde weder iccsn, cardHandle, cardTerminalId noch eine slotId übergeben, so wird ein Informationsobjekt des Konnektors zurückgegeben. Für das Element ErrorCondition ist aus der Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste der Text aus der Spalte ErrorCondition zu übernehmen, ggf. mit den in dieser Spalte angegebenen Parameterwerten.
      Vor der Rückgabe der Informationen über eine Ressource wird geprüft, ob der angegebene Mandant und das angegebene Clientsystem darauf zugreifen dürfen (siehe Zugriffsberechtigungsdienst). Wurde zusätzlich der optionale Parameter workplaceId übergeben, so wird auch geprüft, ob die Ressource diesem Arbeitsplatz zugeordnet ist.
      Die Rückgabe der Informationen erfolgt gemäß dem Schema „Eventservice.xsd“.
    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
    (1)    Ungültige Kartenterminal-ID: Fehlercode: 4007
    (1)    Ungültige Kartenslot-ID: Fehlercode: 4097
    (1)    Keine Karte im angegebenen Slot: Fehlercode: 4098
    (1)    Keine Karte mit angegebener Iccsn gefunden: Fehlercode: 4099
    (1)    Karten-Handle ungültig: Fehlercode: 4101
    (2)    Ungültige Kartenterminal-ID: Fehlercode: 4007
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 141: TAB_KON_562 Fehlercodes TUC_KON_254 „Liefere Ressourcendetails“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4007
    Technical
    Error
    ungültige Kartenterminal-ID
    4097
    Technical
    Error
    ungültige Kartenslot-ID
    4098
    Technical
    Error
    keine Karte im angegebenen Slot gefunden
    4099
    Technical
    Error
    keine Karte zur angegebenen Iccsn gefunden
    4101
    Technical
    Error
    Karten-Handle ungültig

    <=

    4.1.6.5 Operationen an der Außenschnittstelle

    TIP1-A_4603-02

    Der Konnektor MUSS für Clients eine Basisanwendung Systeminformationsdienst anbieten.

    Tabelle 142 TAB_KON_029 Basisanwendung Systeminformationsdienst

    Name
    EventService
    Version
    7.2.0 (WSDL-Version) 7.2.1 (XSD-Version)
    Namensraum
    Siehe GitHub
    Namensraum-Kürzel
    EVT für Schema und EVTW für WSDL
    Operationen
    Name
    Kurzbeschreibung
    GetCardTerminals
    Auflistung der verfügbaren Kartenterminals
    GetCards
    Auflistung der gesteckten Karten
    GetResourceInformation
    Liefert Details zu einer Ressource (Kartenterminal, Karte, HSM)
    Subscribe
    Anmeldung der Zustellung von Ereignissen
    Unsubsribe
    Abmelden von der Zustellung von Ereignissen
    RenewSubscriptions
    Gültigkeit bestehender Subscriptions verlängern
    GetSubscriptions
    Abfrage der angemeldeten Zustellungen von Ereignissen
    WSDL
    EventService.wsdl
    Schema
    EventService.xsd

    <=

    4.1.6.5.1 GetCardTerminals

    TIP1-A_4604

    Der Konnektors MUSS an der Außenschnittstelle eine Operation GetCardTerminals, wie in Tabelle TAB_KON_563 „Operation GetCardTerminals“ beschrieben, anbieten.

    Tabelle 143: TAB_KON_563 Operation GetCardTerminals

    Name

    GetCardTerminals

    Beschrei-bung

    Liefert die Liste der Kartenterminals, auf die der aufrufende Mandant und das aufrufende Clientsystem zugreifen dürfen (siehe Zugriffsberechtigungsdienst) sowie deren aktuelle Verfügbarkeit. Verfügbarkeit bedeutet im Falle eines eHealth-Kartenterminals, dass der Konnektor eine Verbindung zum Kartenterminal aktuell hält.

    Aufruf-parameter




    Name

    Beschreibung

    @mandant-wide

    Wenn „true“, werden alle Kartenterminals zurückgegeben, auf die der Mandant und das aufrufende Clientsystem zugreifen dürfen.
    Wenn „false“ (Standardbelegung), werden nur Kartenterminals zurückgegeben, auf die von dem im Aufrufkontext spezifizierten Arbeitsplatz zugegriffen werden darf.

    Context

    Aufrufkontext

    Rückgabe



    Name

    Beschreibung

    Status

    Ergebnis der Operation




    Die Liste der Kartenterminals

    Name

    Beschreibung

    Product
    Information

    Produktinformationen gemäß [gemSpec_OM] und dem Schema „ProductInformation.xsd“ zu formatieren.

    CtId

    Eineindeutige Identifikation des Kartenterminals

    WorkplaceIds

    Die Liste der Arbeitsplätze, denen das Kartenterminal als lokales Kartenterminal zugeordnet ist. Insbesondere für Entfernte Kartenterminals kann diese Liste leer sein (siehe TUC_KON_252).

    Name

    Sprechender Name des Kartenterminals

    MacAddress

    MAC-Adresse des Kartenterminals

    IPAddress

    IP-Adresse des Kartenterminals

    Slots

    Anzahl der Slots des Kartenterminals

    IS_PHYSICAL

    Attribut des Kartenterminals das anzeigt ob es sich um ein physisches oder logisches Kartenterminal handelt
    (siehe auch TAB_KON_522 Parameterübersicht des Kartenterminaldienstes)

    Connected

    Zeigt an, ob dieses Kartenterminal aktuell verfügbar ist.
    TRUE – ist verfügbar
    FALSE – ist nicht verfügbar

    Vorbedingungen

    Keine

    Nachbedingungen

    Der Zustand der Kartenterminals bleibt unverändert.

    Hinweise

    Der Aufruf DARF nur den im Konnektor verwalteten, aktuellen Zustand des Kartenterminals liefern und DARF NICHT Abfragen an die Kartenterminals absetzen.

    Der Ablauf der Operation GetCardTerminals ist in Tabelle TAB_KON_564 Ablauf GetCardTerminals beschrieben:

    Tabelle 144: TAB_KON_564 Ablauf GetCardTerminals

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.


    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Prüfung der Zugriffsberechtigung durch den Aufruf
    TUC_KON_000 {
          mandantId = $context.mandantId;
          clientSystemId = $context.clientsystemId;
          workplaceId = $context.workplaceId;
          needCardSession = false;
          allWorkplaces = @mandant-wide }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.


    TUC_KON_252 „Liefere KT_Liste“

    Die Liste der Kartenterminals wird erstellt und zurückgegeben. Tritt hierbei ein Fehler auf, so bricht die Operation mit dem Fehler des TUCs ab.
    Wenn @mandant-wide=true dann ermittle die Liste der Kartenterminals für alle Arbeitsplätze des Mandanten für das angegebene Clientsystem durch den Aufruf von TUC_KON_252{
        clientSystemId = $context.ClientSystemId;
        mandantId = $context.mandantId }
    Wenn @mandant-wide=false dann ermittle die Liste der Kartenterminals für den Arbeitsplatz des Mandanten für das angegebene Clientsystem entsprechend $context durch den Aufruf von TUC_KON_252{
        workplaceId = $context.workplaceId;
        clientSystemId = $context.ClientSystemId;
        mandantId = $context.mandantId }


    Tabelle 145: TAB_KON_823 Fehlercodes „GetCardTerminals“

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:

    4000

    Technical

    Error

    Syntaxfehler


    ​​

    <=

    4.1.6.5.2 GetCards

    TIP1-A_4605

    Der Konnektors MUSS an der Außenschnittstelle eine Operation GetCards, wie in Tabelle TAB_KON_565 „Operation GetCards“ beschrieben, anbieten und MUSS dabei Kartentypen aus Tabelle TAB_KON_500 Wertetabelle Kartentypen unterscheiden.

    Tabelle 146: TAB_KON_565 Operation GetCards

    Name
    GetCards    
    Beschreibung
    Liefert Informationen zu den in den Kartenterminals verfügbaren Karten zurück, die in Kartenterminals stecken, auf die Mandant und Clientsystem zugreifen dürfen. Insbesondere umfasst die Information die sog. Karten-Handles. Die Karten-Handles können bei anderen Konnektoraufrufen zur Adressierung von Karten genutzt werden.
    Aufrufparameter



    Name
    Beschreibung
    @mandant-
    wide
    Wenn „true“, werden alle Karten zurückgegeben, auf die der Mandant und das aufrufende Clientsystem zugreifen dürfen. Wenn „false“ (Standardbelegung), werden nur Karten zurückgegeben, auf die von dem im Aufrufkontext spezifizierten Arbeitsplatz zugegriffen werden darf.
    Context
    Aufrufkontext
    CtId
    Identifikation des Kartenterminals. Wenn angegeben, werden nur die Karten zurückgeliefert, die in diesem Kartenterminal verfügbar sind.
    SlotId
    Nummer des Slots, beginnend bei 1.
    Wird zusätzlich zur CtId auch SlotId übergeben, so wird die Karte zurückgegeben, die in dem angegebenen Slot des mit CtId adressierten Kartenterminals steckt.
    CardType
    Ein Kartentyp gemäß Tabelle TAB_KON_500 „Wertetabelle Kartentypen“ als optionaler Filter. Wenn angegeben, werden nur Karten vom spezifizierten Typ zurückgegeben. Unterstützt werden die Kartentypen EGK, KVK, HBAx, SM-B, SMC-KT und UNKNOWN.
    Antwort



    Name
    Beschreibung
    Status
    Ergebnis der Operation
    Im Element Cards wird die Liste der gesteckten Karten zurückgegeben. Für jede Karte wird dabei ein Card-Element angegeben. Leere Slots der Kartenterminals sind in dieser Liste nicht enthalten.


    Name
    Beschreibung
    Card
    Handle
    Handle, mit dem die Karte in Folgeaufrufen adressiert werden kann. Der Konnektor garantiert, dass dieses Handle die gesteckte Karte eindeutig identifiziert und bei Entfernen der Karte aus dem Kartenterminal ungültig wird.
    Auch für nicht erkannte Karten (z. B. bei falscher Steckrichtung der Karte) SOLL der Konnektor gültige Handles liefern (sofern das Kartenterminal in diesem Fall in der Lage ist, das entsprechende Ereignis „Karte wurde gesteckt“ zu liefern), damit diese Karten z. B. zum Auswurf adressiert werden können.
    CardType
    Erkannter Typ der Karte.
    Siehe Tabelle TAB_KON_500 Wertetabelle Kartentypen,
    Card
    Version



    Der Konnektor MUSS in CardVersion bei eGK, HBA und SM-B/SMC-KT der Generation 2 die Versionsinformationen gemäß [gemSpec_Karten_Fach_TIP] übergeben, für G1+ aus /MF/EF.Version.
    Bei KVK, HBA-VK und unbekannten Karten MUSS das Element weggelassen werden.
    Iccsn
    Falls auslesbar, die ICC-Serial-Number der Karte.
    Im Fall der KVK wird das optionale Element Iccsn nicht zurückgegeben.
    CtId
    Identifikation des Kartenterminals, in dem die Karte steckt.
    SlotId
    Nummer des Slots (beginnend bei 1), in dem die Karte steckt.
    InsertTime
    Gibt den Zeitpunkt an, zu dem der Konnektor die Karte erkannt hat.
    Die Zeit wird mit dem Datentyp DateTime in folgendem Format angegeben:
    yyyy-mm-ddThh:mm:ss+hh:mm
    Es ist also – gemäß ISO 8601 [ISO8601] – die lokale Zeit und die Differenz zur UTC anzugeben.
    CardHolder
    Name
    Name des Karteninhabers bzw. der Institution/Organisation (subject.commonName).
    Bei KVK und unbekannten Karten MUSS das Element weggelassen werden.
    Kvnr
    KVNR (Unveränderbarer Teil) MUSS bei eGK belegt werden. Bei allen anderen Karten MUSS das Element weggelassen werden.
    Certificate
    Expiration
    Date
    Ablaufdatum des Zertifikates (AUT bzw. OSIG).
    Bei KVK und unbekannten Karten MUSS das Element weggelassen werden.
    Vorbedingungen
    Keine.
    Nachbedingungen
    Der Zustand der Karten und der Kartenterminals bleibt unverändert.
    Hinweise
    Der Aufruf darf nur den im Konnektor verwalteten aktuellen Zustand der Karte liefern und keine Abfragen an die Kartenterminals absetzen.
    Der Ablauf der Operation GetCards ist in Tabelle TAB_KON_566 Ablauf GetCards beschrieben:

    Tabelle 147: TAB_KON_566 Ablauf GetCards

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.

    TUC_KON_000 „Prüfe Zugriffsberechtigung“

    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
          mandantId = $context.mandantId;
          clientSystemId = $context.clientsystemId;
          workplaceId = $context.workplaceId;
          needCardSession = false;
          allWorkplaces = @mandant-wide}
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.

    TUC_KON_253 „Liefere Karten_Liste“

    Die Liste der Karten wird erstellt und zurückgegeben. Tritt hierbei ein Fehler auf, so bricht die Operation mit dem Fehler des TUCs ab.
    Wenn @mandant-wide=true dann ermittle die Liste der Karten für alle Arbeitsplätze des Mandanten für das angegebene Clientsystem durch den Aufruf
    TUC_KON_253 „Liefere Karten_Liste“ {
        clientSystemId = $context.clientsystemId;
        cardTerminalId = CtId;
        slotId = SlotId;
        mandantId = $context.mandantId;
        cardType = CardType }
    Wenn @mandant-wide=false dann ermittle die Liste der Karten für den Arbeitsplatz des Mandanten für das angegebene Clientsystem entsprechend $context durch den Aufruf
    TUC_KON_253 „Liefere Karten_Liste“ {
        workplaceId= $context.workplaceId;
        clientSystemId = $context.clientsystemId;
        cardTerminalId = CtId;
        slotId = SlotId;
        mandantId = $context.mandantId;
        cardType = CardType }

    Die Fehlerfälle der Operation GetCards sind in Tabelle TAB_KON_567 Fehlercodes „GetCards dargestellt:

    Tabelle 148: TAB_KON_567 Fehlercodes „GetCards“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    <=

    4.1.6.5.3 GetResourceInformation

    TIP1-A_4607

    Der Konnektors MUSS an der Außenschnittstelle eine Operation GetResourceInformation, wie in Tabelle TAB_KON_568 „Operation GetResourceInformation“ beschrieben, anbieten.

    Tabelle 149: TAB_KON_568 Operation GetResourceInformation

    Name
    GetResourceInformation
    Beschreibung
    Gibt Informationen zu einer Ressource (Karte, KT) oder dem Konnektor selbst zurück
    Aufrufparameter


    Name
    Beschreibung
    Context
    Aufrufkontext
    CtId
    Identifikator eines Kartenterminals
    SlotId
    Kartenslot-Nummer (in Kombination mit CtId)
    Iccsn
    Iccsn einer Karte
    CardHandle
    CardHandle einer Karte. Unterstützt werden die Kartentypen EGK, KVK, HBAx, SM-B, SMC-KT und UNKNOWN.
    Wurde keines der Elemente CtId, SlotId, Iccsn übergeben, so wird davon ausgegangen, dass der Aufrufer Informationen zum Konnektor selbst abfragen möchte.
    Rückgabe


    Name
    Beschreibung
    Status
    Ergebnis der Operation
    Card
    Informationen einer Karte (siehe GetCards)
    CardTerminal
    Informationen eines Kartenterminals (siehe GetCardTerminals)
    Connector
    Informationen zum Konnektor



    VPNTIStatus


    VPNTIStatus/
    ConnectionStatus
    Status der VPN-Verbindung zur TI (Online oder Offline)
    VPNTIStatus/
    Timestamp
    Zeitstempel der letzten Statusänderung
    VPNSISSTatus


    VPNSISStatus/
    ConnectionStatus
    Status der VPN-Verbindung des SIS (Online oder Offline)
    VPNSISStatus/
    Timestamp
    Zeitstempel der letzten Statusänderung
    OperatingState
    Betriebszustand (siehe Kapitel 3.3)
    OperatingState/
    ErrorState
    Eine Zeile der Fehlerzustandsliste gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
    OperatingState/
    ErrorState/
    ErrorCondition
    ErrorCondition gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
    OperatingState/
    ErrorState/Severity
    Schwere des Fehlerzustandes gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
    OperatingState/
    ErrorState/Type
    Fehlertyp gemäß Tabelle TAB_KON_503 Betriebszustand_Fehlerzustandsliste
    OperatingState/
    ErrorState/Value
    Fehlerzustandswert
    OperatingState/
    ErrorState/ValidFrom
    Zeitstempel der letzten Änderung des Fehlerzustands
    Vorbedingung


    Nachbedingung
    Der Zustand der Ressource bleibt unverändert.
    Hinweise


    Der Ablauf der Operation GetResourceInformation ist in Tabelle TAB_KON_569 Ablauf GetResourceInformation beschrieben:

    Tabelle 150: TAB_KON_569 Ablauf GetResourceInformation

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.



    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Insbesondere wird geprüft, dass eine SlotId nur in Verbindung mit einer CtId übergeben werden kann (Abfrage einer Karte). Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.



    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Die Prüfung erfolgt,
    falls die Ressource der Konnektor ist, durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        ctId = null;
        cardHandle = null;
        needCardSession = false;
        allWorkplaces = true
    }
    falls die Ressource ein Kartenterminal ist, durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        ctId = $ctId;
        cardHandle = null;
        needCardSession = false;
        allWorkplaces = true
    }
    falls die Ressource eine Karte ist, durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        ctId = null;
        cardHandle = $cardHandle;
        needCardSession = false;
        allWorkplaces = false
    }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.



    TUC_KON_254 „Liefere Ressourcendetails“

    Die Informationen zu der Ressource werden zusammengetragen und zurückgegeben. Tritt hierbei ein Fehler auf, so bricht die Operation mit dem Fehler des TUCs ab.

    Die Fehlerfälle der Operation GetResourceInformation sind in Tabelle TAB_KON_570 Fehlercodes „GetResourceInformation dargestellt:

    Tabelle 151: TAB_KON_570 Fehlercodes „GetResourceInformation“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler


    <=

    4.1.6.5.4 Subscribe

    TIP1-A_4608

    Der Konnektors MUSS an der Außenschnittstelle eine Operation Subscribe, wie in Tabelle TAB_KON_571 Operation Subscribe beschrieben, anbieten.

    Tabelle 152: TAB_KON_571 Operation Subscribe

    Name

    Subscribe

    Beschreibung

    Clientsysteme melden mit dieser Operation ihr Interesse an bestimmten Topics (Ereignissen) an.

    Aufrufparameter



    Name

    Beschreibung

    Context

    Aufrufkontext

    SubscriptionID

    Darf nicht verwendet werden

    TerminationTime

    Darf nicht verwendet werden

    EventTo

    URL des Endpunkts, wo die Ereignisse zugestellt werden sollen. Syntax: cetp://host:port
    host: IP-Adresse oder FQDN des Clientsystems.
    port: Portnummer des Kommunikationsendpunkts, an dem das Clientsystem auf die Zustellung der Ereignisse wartet.

    Topic

    Ein Topic, für das das Clientsystem sein Interesse anmeldet.

    Filter

    Filter für die Ereignisnachricht (X-Path Ausdruck im Kontext mit Default Namespace gleich "http://ws.gematik.de/conn/EventService/v7.2" ohne Verwendung eines Namespace-Präfixes sowie Namensraum mit Präfix EVT gleich "http://ws.gematik.de/conn/EventService/v7.2", der beim Versand von Ereignissen in TUC_KON_256 ausgewertet wird. Ermöglicht die Filterung auf Basis der Elemente einer XML-Ereignisnachricht)

    Rückgabe



    Name

    Beschreibung

    Status

    Ergebnis der Operation

    SubscriptionID

    Ein Identifikator, der die Anmeldung für die Topics eindeutig identifiziert. Bei den Operationen Unsubscribe, GetSubscription und RenewSubsriptions MUSS dieser SubscriptionID angegeben werden.

    TerminationTime

    Maximaler Gültigkeitszeitpunkt der Subscription. Sie MUSS auf Systemzeit + 25 h gesetzt werden.

    Vorbedingung

    Das Clientsystem muss die Ereignissenke realisieren.

    Nachbedingung

    Nach erfolgreicher Anmeldung vermerkt der Konnektor das angemeldete Topic unter dem SubscriptionID.
    Der Konnektor muss die Anmeldungen so lange als gültig behandeln, bis entweder das Clientsystem diese explizit abmeldet oder der Konnektor das Clientsystem als nicht mehr erreichbar erkennt (siehe nächsten Punkt) oder der Konnektor neu gestartet oder ausgeschaltet wird oder die TerminationTime kleiner als die Systemzeit ist.
    Der Konnektor muss die Anmeldung aus seiner Verwaltung entfernen („Auto-Unsubscribe“), wenn EVT_MAX_TRY Verbindungsaufbauversuche oder zählbare Zustellungsversuche (z.B. durch Zählung beim Absenden der Zustellversuche) in Folge fehlgeschlagen sind. Wenn die Ereignissenke Zustellungen grundsätzlich nicht beantwortet, so sind nur die Verbindungsaufbauversuche zu zählen.

    Hinweise


    Der Ablauf der Operation Subscribe ist in Tabelle TAB_KON_572 Ablauf Subscribe beschrieben:

    Tabelle 153: TAB_KON_572 Ablauf Subscribe

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.


    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 _000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        needCardSession = false;
        allWorkplaces = true }
    Tritt bei der Prüfung ein Fehler auf, so bricht die Operation mit dem Fehlercode aus TUC_KON_000 ab.

    3.


    saveSubscription

    Die Anmeldung wird im Konnektor hinterlegt. Vorgehalten werden folgende Daten:

    • SubscriptionId (wird generiert)

    • TerminationTime (Systemzeit + 25h)

    • MandantId

    • ClientsystemId

    • WorkplaceId

    • Ereignissenke (Feld EventTo)

    • Abonnierter Topic (Feld Topic)

    • Filterausdruck (Feld Filter)

    Bei der Übernahme wird eine eindeutige SubscriptionId generiert, die dem aufrufenden System zurückgegeben wird, falls die Subscription noch nicht existiert. Existiert sie bereits, wird die bestehende SubscriptionID zurückgegeben.

    Die Fehlerfälle der Operation Subscribe sind in Tabelle TAB_KON_573 Fehlercodes „Subscribe dargestellt:

    Tabelle 154 TAB_KON_573 Fehlercodes „Subscribe“

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:

    4000

    Technical

    Error

    Syntaxfehler


    ​​

    <=

    4.1.6.5.5 Unsubscribe

    TIP1-A_4609

    Der Konnektors MUSS an der Außenschnittstelle eine Operation Unsubscribe, wie in Tabelle TAB_KON_574 Operation Unsubscribe beschrieben, anbieten.

    Tabelle 155: TAB_KON_574 Operation Unsubscribe

    Name

    Unsubscribe

    Beschreibung

    Löscht eine Anmeldung mit dem angegebenen SubscriptionID oder alle Anmeldungen zu einem Endpunkt EventTo.

    Aufrufparameter



    Name

    Beschreibung

    Context

    Aufrufkontext

    SubscriptionID

    Der Identifikator, der bei der Subscribe-Operation geliefert wurde.

    EventTo

    URL des clientseitigen Endpunkts, wie er bei der Subscribe-Operation angegeben wurde.

    Rückgabe


    Name

    Beschreibung

    Status

    Ergebnis der Operation

    Vorbedingung

    Die Anmeldung Subscribe muss vor dieser Operation aufgerufen worden sein.

    Nachbedingung

    Der Konnektor entfernt aus seiner Verwaltung die Subscription zur Subscription-ID bzw. alle Subscriptions zur clientseitigen URL des Endpunkts EventTo.

    Hinweise

    Keine

    Der Ablauf der Operation Unsubscribe ist in Tabelle TAB_KON_575 Ablauf Unsubscribe beschrieben:

    Tabelle 156: TAB_KON_575 Ablauf Unsubscribe

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.

    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
          mandantId = $context.mandantId;
          clientsystemId  = $context.clientsystemId;
          workplaceId = $context.workplaceId;
          needCardSession = false;
          allWorkplaces = true }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.

    removeSubscription

    Entfernen der Subscriptions aus der Liste aller Subscriptions.

    Die Fehlerfälle der Operation Unsubscribe sind in Tabelle TAB_KON_576 Fehlercodes „Unsubscribe dargestellt:

    Tabelle 157: TAB_KON_576 Fehlercodes „Unsubscribe“

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:

    4000

    Technical

    Error

    Syntaxfehler

    4102

    Technical

    Error

    ungültige SubscriptionId


    ​​

    <=

    4.1.6.5.6 RenewSubscriptions

    TIP1-A_5112

    Der Konnektors MUSS an der Außenschnittstelle eine Operation RenewSubscriptions, wie in Tabelle TAB_KON_792 Operation RenewSubscriptions beschrieben, anbieten.

    Tabelle 158: TAB_KON_792 Operation RenewSubscriptions

    Name

    RenewSubscriptions

    Beschreibung

    Verlängert die Gültigkeit einer Liste von Anmeldungen, die jeweils per SubscriptionID identifiziert werden.

    Aufrufparameter



    Name

    Beschreibung

    Context

    Aufrufkontext

    Subscription
    ID

    Der Identifikator, der bei der Subscribe-Operation geliefert wurde.

    Rückgabe



    Name

    Beschreibung

    Status

    Ergebnis der Operation

    Subscription
    ID

    Ein Identifikator, der die Anmeldung für die Topics eindeutig identifiziert. Bei den Operationen Unsubscribe, GetSubscription und RenewSubsriptions MUSS diese SubscriptionID angegeben werden.

    Termination
    Time

    Maximaler Gültigkeitszeitpunkt der Subscription. Sie MUSS auf Systemzeit + 25 h gesetzt werden.

    Vorbedingung


    Nachbedingung

    Der Konnektor speichert jede neu vergebene TerminationTime in seiner Verwaltung der Subscriptions.

    Hinweise

    Keine

    Der Ablauf der Operation RenewSubscriptions ist in Tabelle TAB_KON_793 Ablauf RenewSubscriptions beschrieben:

    Tabelle 159: TAB_KON_793 Ablauf RenewSubscriptions

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.


    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
          mandantId = $context.mandantId;
          clientsystemId  = $context.clientsystemId;
          workplaceId = $context.workplaceId;
          needCardSession = false;
          allWorkplaces = true }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.


    renewSubscriptions

    Es wird eine neue SubscribeRenewals-Liste angelegt.
    Alle Subscriptions, deren TerminationTime kleiner als die Systemzeit sind, muss der Konnektor aus der Verwaltung entfernen.
    Für jede SubscriptionID, die in der Verwaltung der Subscriptions existiert und deren TerminationTime größer als die Systemzeit ist, wird eine neue TerminationTime = Systemzeit + 25h bestimmt. Diese wird zusammen mit der SubscriptionID als SubscribeRenewal der SubscribeRenewals-Liste hinzugefügt.
    Kommt es zu keiner Subscription-Verlängerung, weil nur ungültige SubscriptionIDs im Aufruf angegeben waren, wird der Fehler 4102 zurückgeliefert. Kommt es zu mindestens einer Subscription-Verlängerung, sind aber auch ungültige SubscriptionIDs im Aufruf, wird eine RenewSubscriptionsResponse zurückgeliefert, mit CONN:Status/CONN:Result = "Warning", GERROR:Trace mit {Fehlercode: 4102, ErrorType: Technical, Severity: Error, Fehlertext: "Ungültige SubscriptionId"}, und der Information, welche SubscriptionsIDs ungültig waren.

    Die Fehlerfälle der Operation RenewSubscriptions sind in Tabelle TAB_KON_794 Fehlercodes „RenewSubscriptions dargestellt:

    Tabelle 160: TAB_KON_794 Fehlercodes „RenewSubscriptions“

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:

    4000

    Technical

    Error

    Syntaxfehler

    4102

    Technical

    Error

    Ungültige SubscriptionId


    ​​

    <=

    4.1.6.5.7 GetSubscription

    TIP1-A_4610

    Der Konnektor MUSS an der Außenschnittstelle eine Operation GetSubscription, wie in Tabelle TAB_KON_577 Operation GetSubscription beschrieben, anbieten.

    Tabelle 161: TAB_KON_577 Operation GetSubscription

    Name

    GetSubscription

    Beschreibung

    Gibt die Liste der angemeldeten Topics zurück

    Aufrufparameter


    Name

    Beschreibung

    @mandant-wide

    Wenn „true“, werden alle Subscriptions zurückgegeben, die Mandant und Clientsystem zugeordnet sind.
    Wenn „false“ (Standardbelegung) werden alle Subscriptions zurückgegeben, die dem im Aufrufkontext spezifizierten Tripel aus Clientsystem, Mandanten und  Arbeitsplatz zugeordnet sind.

    Context

    Aufrufkontext

    SubscriptionID

    Der Identifikator, der bei der Subscribe-Operation geliefert wurde.

    Rückgabe



    Name

    Beschreibung

    Status

    Ergebnis der Operation

    Subscriptions

    Die Liste Subscriptions (vgl. Operation Subscribe)



    Subscription

    Angefordertes Subscription-Element

    Subscription/
    SubscriptionID

    Identifikator der Subscription

    Subscription/
    TerminationTime

    Maximaler Gültigkeitszeitpunkt der Subscription.

    Subscription/
    EventTo

    URL des Endpunkts, wo die Ereignisse zugestellt werden sollen (Ereignissenke)

    Subscription/
    Topic

    Angemeldeter Topic

    Subscription/
    Filter

    Filterausdruck (falls vorhanden)

    Vorbedingung

    Keine

    Nachbedingung

    Die Liste der Subscriptions bliebt unverändert

    Hinweise

    Keine

    Der Ablauf der Operation GetSubscription ist in Tabelle TAB_KON_578 Ablauf GetSubscription beschrieben:

    Tabelle 162: TAB_KON_578 Ablauf GetSubscription

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.


    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        needCardSession = false;
        allWorkplaces = @mandant-wide }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.


    getSubscriptions

    Rückgabe der Subscription, die durch SubscriptionId identifiziert wird.
    Wurde keine SubscriptionId angegeben und @mandant-wide="true", werden alle Subscriptions zurückgegeben, die dem angegebenen Clientsystem und Mandanten zugeordnet werden können.
    Wurde keine SubscriptionId angegeben und @mandant-wide="false", werden alle Subscriptions zurückgegeben, die dem angegebenen Clientsystem, Mandanten und Arbeitsplatz zugeordnet werden können.

    Die Fehlerfälle der Operation GetSubscription sind in Tabelle TAB_KON_579 Fehlercodes „GetSubscription dargestellt:

    Tabelle 163: TAB_KON_579 Fehlercodes „GetSubscription“

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten:

    4000

    Technical

    Error

    Syntaxfehler

    4102

    Technical

    Error

    ungültige SubscriptionId


    ​​

    <=

    4.1.6.6 Betriebsaspekte

    TIP1-A_4611

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_580 vorzunehmen:


    Tabelle 164: TAB_KON_580 Konfigurationswerte des Systeminformationsdienstes (Administrator)

    ReferenzID

    Belegung

    Bedeutung und Administrator-Interaktion

    EVT_MAX_TRY

    Nummer

    Der Administrator MUSS über diesen Konfigurationsparameter die Anzahl der Fehlversuche bzgl. Verbindungsversuche bzw. Ereigniszustellungen festlegen können.  

    Ist diese maximal zulässige Anzahl der Fehlversuche überschritten, muss der Konnektor automatisch ein „Auto-Unsubscribe (analog Operation „Unsubscribe mit „EventTo gleich der URL des clientseitigen Endpunkts) durchführen.


    <=

    TIP1-A_4612

    Der Konnektor MUSS eine Mindestmenge von 999 Subscriptions insgesamt unterstützen. Der Konnektorhersteller kann jedoch die Anzahl der maximal möglichen Subscriptions (insgesamt und/oder pro Ziel) festlegen.

    <=

    TIP1-A_4613

    Der Konnektor MUSS beim Bootup mit einer leeren Liste an Subscriptions starten.

    <=

    4.1.7 Verschlüsselungsdienst

    Der Verschlüsselungsdienst bietet Schnittstellen zum hybriden und symmetrischen Ver- und Entschlüsseln von Dokumenten an.

    Der Verschlüsselungsdienst bietet für alle Alle_DocFormate die hybride und symmetrische Ver- und Entschlüsselung nach dem Cryptographic Message Syntax (CMS) Standard an [RFC5652].

    Darüber hinaus werden folgende formaterhaltende Ver-/Entschlüsselungsmechanismen unterstützt:

    Der Konnektor kann optional folgende formaterhaltende Ver-/Entschlüsselungsmechanismen unterstützen:

    Dabei soll der Konnektor, wenn er die S/MIME-Verschlüsselung unterstützt, auch die S/MIME-Entschlüsselung unterstützen.

    Der Konnektor muss bezüglich der zur Ver- und Entschlüsselung von Dokumenten verwendeten Verfahren und Algorithmen die Vorgaben in [gemSpec_Krypt#3.1.4] sowie in [gemSpec_Krypt#3.1.5] und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] erfüllen.

    4.1.7.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4614

    Der Konnektors MUSS zur Unterstützung von Missbrauchserkennungen die in Tabelle TAB_KON_581 gelisteten Operationen als Einträge in EVT_MONITOR_OPERATIONS berücksichtigen.


    Tabelle 165: TAB_KON_581 Verschlüsselungsdienst-Operationen für EVT_MONITOR_OPERATIONS

    Operationsname

    OK_Val

    NOK_Val

    Alarmwert (Default-Grenzwert 10 Minuten-Σ)

    EncryptDocument

    1

    5

    101

    DecryptDocument

    1

    5

    101


    <=

    TIP1-A_5434

    Der Konnektor MUSS das Operationspaar Verschlüsselung/Entschlüsselung so implementieren, dass Dokumente vom Typ XML unverändert bleiben, wobei zwei XML-Dokumente als identisch zu betrachten sind, wenn sie gemäß Canonical XML 1.1 gleich sind [CanonXML1.1]. <=

    A_17746

    Der Konnektor MUSS für die kartenbasierte Ver- und Entschlüsselung die Zertifikate und Schlüssel in Abhängigkeit vom kryptographischen Verfahren unter Berücksichtigung des Einsatzbereiches aus TAB_KON_747 ermitteln. <=

    Tabelle 166: TAB_KON_747 KeyReference für Encrypt-/DecryptDocument

    Karte
    KeyReference 
    Crypt
    Zertifikat (Encrypt)
    ...in DF.ESIGN
    Schlüssel (Decrypt)
    ...in DF.ESIGN
    Einsatzbereich
    Außen-schnittstelle
    Fachmodul-schnittstelle
    HBA
    C.ENC
    RSA_ECC
    EF.C.HP.ENC.R2048
    EF.C.HP.ENC.E256
    PrK.HP.ENC.R2048
    PrK.HP.ENC.E256
    Ja
    Ja
    ECC
    EF.C.HP.ENC.E256
    PrK.HP.ENC.E256
    Ja
    Ja
    RSA
    EF.C.HP.ENC.R2048
    PrK.HP.ENC.R2048
    Ja
    Ja
    SM-B
    C.ENC
    RSA_ECC
    EF.C.HCI.ENC.R2048
    EF.C.HCI.ENC.E256
    PrK.HCI.ENC.R2048
    PrK.HP.ENC.E256
    Ja
    Ja
    ECC
    EF.C.HCI.ENC.E256
    PrK.HP.ENC.E256
    Ja
    Ja
    RSA
    EF.C.HCI.ENC.R2048
    PrK.HCI.ENC.R2048
    Ja
    Ja
    HBA-VK
    C.ENC
    RSA_ECC
    RSA
    EF.C.HP.ENC
    PrK.HP.ENC
    Ja
    Ja
    eGK
    C.ENC
    ECC
    C.CH.ENC.E256
    PrK.CH.ENC.E256
    Nein
    Ja
    C.ENC
    RSA
    C.CH.ENC.R2048
    PrK.CH.ENC.R2048
    Nein
    Ja

    Tabelle 167: TAB_KON_859 Werteliste und Defaultwert des Parameters crypt bei hybrider Verschlüsselung

    Typname
    Werteliste
    Defaultwert
    Bedeutung
    ENC_CRYPT
    RSA
    ECC
    RSA_ECC
    RSA
    Werteliste des Parameters crypt bei der hybriden Verschlüsselung
    RSA: Es wird RSA-2048 basiert verschlüsselt.
    ECC: Es wird ECC-256 basiert verschlüsselt.
    RSA_ECC: Es wird dual RSA-2048 basiert und ECC-256 basiert verschlüsselt. Es wird als Fehlerfall gewertet, wenn weder RSA- noch ECC-Zertifikat von der Karte geladen werden konnten, und als Warnung, wenn nur ein Zertifikat geladen werden konnte.
    4.1.7.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.1.7.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.1.7.4 Interne TUCs, auch durch Fachmodule nutzbar

    Die in diesem Kapitel beschriebenen TUCs zur hybriden Ver- und Entschlüsselung werden den Fachmodulen und Außenoperationen angeboten. Die TUCs zur symmetrischen Ver-/Entschlüsselung werden den Fachmodulen angeboten. Es gibt keine Aufrufhierarchie innerhalb der hier beschriebenen TUCs zur hybriden und symmetrischen Ver-/Entschlüsselung.

    4.1.7.4.1 TUC_KON_070 „Daten hybrid verschlüsseln”

    TIP1-A_4616-03

    Der Konnektor MUSS den technischen Use Case TUC_KON_070 „Daten hybrid verschlüsseln” umsetzen.

    Tabelle 168: TAB_KON_739 - TUC_KON_070 „Daten hybrid verschlüsseln“

    Element
    Beschreibung
    Name
    TUC_KON_070 „Daten hybrid verschlüsseln“
    Beschreibung
    Dieser TUC verschlüsselt ein Dokument oder Teile eines Dokumentes. Die Verschlüsselung erfolgt zweistufig, d. h. die Daten werden symmetrisch mit einem generierten Schlüssel verschlüsselt und anschließend wird dieser Schlüssel mit einem asymmetrischen Verfahren verschlüsselt.
    Die asymmetrische Verschlüsselung des symmetrischen Schlüssels kann für mehrere Identitäten, repräsentiert durch X.509-Zertifikate oder öffentliche Schlüssel, erfolgen. Das Ergebnis sind entsprechend viele Verschlüsselungen desselben symmetrischen Schlüssels.
    Es werden die folgenden formaterhaltenden Verschlüsselungsverfahren für die genannten Dokumententypen unterstützt:
    • XML mit [XMLEnc]
    • MIME mit [S/MIME]
    Des Weiteren ist für alle unterstützten Dokumentformate (Alle_DocFormate) die Verschlüsselung mit CMS [RFC5652] möglich.
    Auslöser
    Aufruf durch einen Fachmodul-TUC oder durch die Operation EncryptDocument des Verschlüsselungsbasisdienstes
    Vorbedingungen
    Falls mit einem öffentlichen Schlüssel auf einer Karte verschlüsselt werden soll, muss die Karte gesteckt sein.
    Eingangsdaten
    • documentToBeEncrypted
      (Zu verschlüsselndes Dokument )
    • encryptionCertificates – optional/entfällt, wenn encryptionKeys übergeben wird
      (X.509v3-Zertifikate)
    • encryptionKeys – optional/entfällt, wenn encryptionCertificates übergeben wird
      (öffentliche Schlüssel; unterstützte Karten sind SM-B, HBAx und eGK)
    • encryptionType [EncryptionType]
      (Angaben zum einzusetzenden Verschlüsselungsverfahren (CMS, XMLEnc oder S/MIME)).
    • cardSession – optional/verpflichtend, wenn ein Zertifikat von einer Karte gelesen werden soll
      (Kartensitzung; unterstützte Karten sind SM-B, HBAx und eGK.)
    • certificateReference – optional/verpflichtend, wenn ein Zertifikat von einer Karte gelesen werden soll
      (Zertifikatsreferenz; unterstützte Karten sind SM-B, HBAx und eGK).
    • crypt [ENC_CRYPT] - optional;
      default und Wertebereich siehe TAB_KON_859
      (Wenn das Verschlüsselungszertifikat von einer Karte kommt, steuert crypt, mit welchen kryptographischen Verfahren die Verschlüsselung der Hybridschlüssel erfolgt.)
    • xmlElements – optional/verpflichtend, wenn encryptionType  = XMLEnc
      (Festlegung der zu verschlüsselnden Teile des Dokumentes durch Spezifikation eines Xpath-Ausdruckes (XML-Elements).
    • keyInfoMode [embedded | separate] – optional/verpflichtend, wenn encryptionType = XMLEnc
      (Angabe, ob die KeyInfo in das XML-Dokument eingebettet oder separat an den Aufrufer zurückgegeben werden soll)
    Komponenten
    Konnektor, Kartenterminal, Karte
    Ausgangsdaten
    • encryptedDocument
      (Verschlüsseltes Dokument)
    • encryptedKeys – optional/verpflichtend, wenn diese nicht im verschlüsselten Dokument enthalten sind
      (Verschlüsselte symmetrische Schlüssel)
    • keyInfo – optional/verpflichtend, wenn encryptionType = XMLEnc  und keyInfoMode = separate
      (KeyInfo, falls nicht ins Dokument eingebettet)
    Standardablauf

    1. Es wird geprüft, ob encryptionCertificates die maximal unterstützte Anzahl überschreitet.
    2. Das Verschlüsselungsverfahren wird anhand des Eingangsparameters EncryptionType gewählt.
    3. Nur für XMLEnc:
      Die zu verschlüsselnden XML-Elemente werden lokalisiert. Falls kein zu verschlüsselndes XML-Element gefunden wurde, wird Fehler 4103 gemeldet. Die zu verschlüsselnden XML-Elemente dürfen nicht ineinander verschachtelt sein. Sind die zu verschlüsselnden XML-Elemente ineinander verschachtelt, so wird Fehler 4104 gemeldet.
    4. Für jedes von der Karte zu lesende Zertifikat, wird TUC_KON_216 „Lese Zertifikat” aufgerufen.
      Welches Zertifikat von der Karte gelesen werden soll, wird durch den Parameter crypt über Tabelle TAB_KON_747 gesteuert.
      In den Fällen crypt = RSA und crypt = ECC bricht der TUC ab, wenn dabei ein Fehler auftritt.
      Im Fall crypt = RSA_ECC bricht der TUC im Fehlerfall dann ab, wenn weder RSA- noch ECC-Zertifikat geladen werden konnte, und läuft mit einer Warnung durch, wenn nur ein Zertifikat geladen werden konnte.
    5. Falls Zertifikate übergeben oder von der Karte gelesen wurden, werden diese durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ geprüft.
      Als Parameter des TUC-Aufrufs gilt für Zertifikate, die mit Zertifikaten  aus CERT_IMPORTED_CA_LIST geprüft werden:
      TUC_KON_037 „Zertifikat prüfen“ {
          certificate =Zertifikat;
          qualifiedCheck = not_required;
          offlineAllowNoCheck = true;
         intendedKeyUsage= intendedKeyUsage(Zertifikate  aus CERT_IMPORTED_CA_LIST);
          validationMode = NONE }

      Für alle anderen Zertifikate gilt: {
          certificate = [C.CH.ENC];
          qualifiedCheck=not_required;
          offlineAllowNoCheck=false;
          policyList =[ oid_egk_enc];
          intendedKeyUsage= intendedKeyUsage(C.CH.ENC);
          validationMode=OCSP }  
      oder
      {
          certificate = [C.CH.ENCV];
          qualifiedCheck=not_required;
          offlineAllowNoCheck=false;
          policyList =[ oid_egk_encv ];
          intendedKeyUsage= intendedKeyUsage(C.CH.ENCV);
          validationMode=OCSP }
      oder
      {
          certificate = [C.HCI.ENC];
          qualifiedCheck=not_required;
          offlineAllowNoCheck=false;
          policyList =[ oid_smc_b_enc ];
          intendedKeyUsage= intendedKeyUsage(C.HCI.ENC);
          validationMode=OCSP }
      oder
      {
          certificate = [C.HP.ENC];
          qualifiedCheck=not_required;
          offlineAllowNoCheck=false;
          policyList =[ oid_hba_enc, oid_vk_pt_enc, oid_vk_eaa_enc ];
          intendedKeyUsage= intendedKeyUsage(C.HP.ENC);
          validationMode=OCSP }
    6. Die öffentlichen Schlüssel werden aus den Zertifikaten extrahiert, falls sie nicht direkt übergeben wurden.
      Falls ein Schlüssel keinen der zugelassenen Verschlüsselungsalgorithmen gemäß [gemSpec_Krypt#3.5.2] bzw. [gemSpec_Krypt#5.8] erlaubt, wird Fehler 4200 gemeldet.
    7. Der Konnektor generiert einen symmetrischen Schlüssel. Dabei muss der symmetrische Schlüssel den Kriterien aus [gemSpec_Krypt#2.4] entsprechen.
    8. Der Konnektor verschlüsselt das Dokument oder Teile des Dokuments mit dem generierten symmetrischen Schlüssel.
      1.         CMS:
        Es MÜSSEN die Vorgaben aus [gemSpec_Krypt#3.5.1] beachtet werden.
      2.         XMLEnc:
        Alle zu verschlüsselnden XML-Elemente werden mit demselben symmetrischen Schlüssel verschlüsselt. Dabei MÜSSEN die Vorgaben aus [gemSpec_Krypt#3.1.4] beachtet werden.
    9. Der symmetrische Schlüssel wird asymmetrisch für die einzelnen Identitäten verschlüsselt. Dabei müssen die Vorgaben aus [gemSpec_Krypt#3.1.5; 3.5.2; 5.8] beachtet werden.
    10. Das Zieldokument wird erstellt.
      XMLEnc
      Format und Inhalt des verschlüsselten Dokuments SOLLEN dem XML Encryption Format in [COMMON_PKI#Part 8] folgen. Zum Format des verschlüsselten XML-Dokumentes siehe auch Tabelle TAB_KON_073 Vorgaben zum Format verschlüsselter XML-Dokumente.
      Die verschlüsselten Datenelemente (EncryptedData) werden erstellt.
      EncryptedData ersetzt jeweils das zu verschlüsselnde Element des XML-Dokuments. In [COMMON_PKI] wird die Verwendung des Attributs Type in EncryptedData ausgeschlossen; diese Spezifikation sieht jedoch dessen Verwendung für verschlüsselte XML-Bestandteile (element, content) wie in [XMLEnc] beschrieben vor. Der Namespace von EncryptedData ist als http://www.w3.org/2001/04/xmlenc# anzugeben.

      Für das Element EncryptedData wird das Sub-Element EncryptionMethod mit Angaben zum Verschlüsselungsalgorithmus als obligatorisch vorgegeben, ebenso die Elemente KeyInfo und CipherData.
      Das Element EncryptedData/KeyInfo hat den Namespace "http://www.w3.org/2000/09/xmldsig#". Es muss pro Hybridschlüssel ein Element EncryptedKey enthalten.
      In jedem EncryptedKey-Element wird neben dem eigentlichen Hybridschlüssel ein Element zur EncryptionMethod der asymmetrischen Verschlüsselung und ein KeyInfo-Element mit dem Zertifikat angelegt, das für die Verschlüsselung des symmetrischen Schlüssels verwendete wurde. Das Zertifikat wird jeweils im Element EncryptedKey/KeyInfo/X509Data/X509Certificate base64-kodiert und darin DER-kodiert abgelegt.
      Hybridschlüssel (RSA):
      Das Element EncryptedData/KeyInfo/EncryptedKey muss die Verschlüsselungsmethode im Element EncryptionMethod angeben, den hybridSchlüssel im Element CipherData speichern und das Zertifikat, mit dem der symmetrische Schlüssel zum Hybridschlüssel verschlüsselt wurde, im Element EncryptedKey/KeyInfo/X509Data/X509Certificate base64-kodiert und darin DER-kodiert ablegen.
      Hybridschlüssel  (ECC): Es gelten die Vorgaben aus [gemSpec_Krypt#5.8]
      CMS:
      Es ist CMS mit Authenticated-Enveloped-Data Content Type gemäß [RFC-5083] und der AES-GCM-Encryption gemäß [RFC-5084] zu verwenden. Bei der Verschlüsselung des „content-encryption key“ wird die Technik „key transport“ eingesetzt. Pro Empfänger wird eine Instanz vom Typ KeyTransRecipientInfo erzeugt. Dabei ist für RecipientIdentifier die Option IssuerAndSerialNumber zu wählen.
      ContentType = OID {… authEnvelopedData}
                          = 1.2.840.113549.1.9.16.1.23
      Im Fall ECC sind die Vorgaben aus [gemSpec_Krypt#5.8] zur Erzeugung des Hybridschlüssels zu beachten.
      Im Fall RSA sind die Vorgaben aus [gemSpec_Krypt#3.5.2] zur Erzeugung des Hybridschlüssels zu beachten.
    1. Der symmetrische Schlüssel wird aktiv gelöscht (überschrieben).
    Varianten/
    Alternativen
    Zur Rückgabe der Hybridschlüssel MUSS auch die Variante vorgesehen werden, dass die Hybridschlüssel („KeyInfo“) nicht eingebettet im Zieldokument zurückgegeben werden, sondern separat.
    Im Fall des Verschlüsselungsverfahrens S/MIME wird der Standardablauf des CMS Verschlüsselungsverfahrens durch einen vorgelagerten S/MIME-Vorbereitungsschritt und einen nachgelagerten S/MIME-Nachbereitungsschritt ergänzt. Das S/MIME-Verfahren MUSS konform [S/MIME] und SOLL konform [COMMON_PKI#Part 3] erfolgen.
    Der S/MIME-Vorbereitungsschritt bereitet das übergebene MIME-Dokument gemäß [S/MIME#3.1] auf die nachfolgende CMS-Verschlüsselung durch eine Kanonisierung für Text [S/MIME#3.1.1] vor. Eine weitere Kanonisierung oder eine Anpassung des Transfer Encodings [S/MIME#3.1.2] erfolgt nicht.
    Im S/MIME-Nachbereitungsschritt wird das im Standardablauf erzeugt CMS-Objekt in eine MIME-Nachricht vom Typ „application/pkcs7-mime“ eingebettet.
    Sämtliche Header-Felder der Nachricht MÜSSEN in die Header-Felder der S/MIME-Nachricht übernommen werden. Die im Folgenden explizit zu setzenden Header-Felder überschreiben die betroffenen Header-Felder.
    Es MUSS ein neues message-id Element für den S/MIME-Header generiert werden.
    "MIME-Version: 1.0" MUSS definiert sein.
    Das Feld "Subject" MUSS mit "Subject: Verschlüsselte Nachricht" überschrieben werden.
    Die Codierung des verschlüsselten Inhalts der Nachricht MUSS in "base64" erfolgen. Entsprechend ist das zugehörige Header-Feld zu füllen: "Content-Transfer-Encoding: base64".
    Das Feld "Content-Type:" ist als "application/pkcs7-mime" zu definieren. Die weiteren Attribute dieses Feldes sind:
    • "smime-type=enveloped-data;"
    • "name=$dateiname", wobei $dateiname auf ".p7m" endet.
    Das Feld "Content-Disposition" definiert den Inhalt der Nachricht als Dateianhang: "Content-Disposition: attachment; filename=$dateiname"
    Zu Schr
    itten 6 und 9 für TI-fremde X.509-Zertifikate
    Der Konnektor MUSS beim asymmetrischen Anteil der hybriden Verschlüsselung auch TI-fremde X.509-Zertifikate unterstützen, wenn diese von einem CA-Zertifikat aus CERT_IMPORTED_CA_LIST ausgestellt wurden und die kryptographischen Vorgaben aus Tabelle  [gemSpec_Krypt#Tab_KRYPT_002] erfüllen.
    Der Konnektor MUSS Anfragen zur Hybridverschlüsselung mit einer Fehlermeldung (Fehler 4200) abweisen, wenn hierfür TI-fremde X509-Zertifikate vorgegeben werden, die nicht die kryptographischen Vorgaben aus Tabelle  [gemSpec_Krypt#Tab_KRYPT_002] oder [gemSpec_Krypt#Tab_KRYPT_002a] erfüllen.
    Fehlerfälle
    Siehe Tabelle TAB_KON_740 Fehlercodes TUC_KON_070 „Daten hybrid verschlüsseln“. Wenn im Ablauf des TUCs ein anderer Fehler als die in Tabelle TAB_KON_740 beschriebenen Fehler auftritt, wird Fehler 4105 gemeldet.

    (->1) maximale Anzahl von Empfängern überschritten: Fehlercode 4282

    (->5) Schritt 5 – Zertifikatsprüfung „für alle anderen Zertifikate“
    Für MGM_LU_ONLINE=Enabled gilt:
    Liefert die Zertifikatsprüfung (OCSP-Abfrage) mdt. eine der folgenden Warnungen gemäß [gemSpec_PKI#Tab_PKI_274]
    • CERT_REVOKED
    • CERT_UNKNOWN
    dann wird der TUC mit Fehler 4105 abgebrochen,

    Ausnahme: Falls im Falle crypt=RSA_ECC der Hybridschlüssel nur für eines der beiden Zertifikate erzeugt werden konnte, dann wird die Warnung 4259 mit <Zertifikat> gemäß TAB_KON_747 in der Response zurückgegeben.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    Abbildung PIC_KON_058 Aktivitätsdiagramm „Daten hybrid verschlüsseln“
    Das Diagramm dient nur der Veranschaulichung und ist nicht vollständig. Beispielsweise enthält es nicht die Steuerung durch den Parameter crypt.



    Abbildung 13: PIC_KON_058 Aktivitätsdiagramm „Daten hybrid verschlüsseln“


    Tabelle 169: TAB_KON_073 Vorgaben zum Format verschlüsselter XML-Dokumente

    #
    Beschreibung

    xenc:EncryptedData MUSS ein ds:KeyInfo Element enthalten, welches wiederum ein xenc:EncryptedKey Element enthält.

    Der xenc:EncryptedKey MUSS [XMLEnc] konform sein.

    Die xenc:EncryptionMethod für den Schlüssel MUSS gemäß [gemSpec_Krypt#3.1.5] gewählt werden

    Der xenc:EncryptedKey MUSS ein ds:KeyInfo Element mit ds:X509Data und ds:X509Certificate Subelement enthalten, in dem das X.509-Zertifikat hinterlegt wird.


    Tabelle 170: TAB_KON_740 Fehlercodes TUC_KON_070 „Daten hybrid verschlüsseln“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4103
    Technical
    Error
    XML-Element nicht gefunden
    4104
    Technical
    Error
    XML-Element nicht eindeutig identifiziert. (Überschneidung)
    4105
    Technical
    Error
    hybride Verschlüsselung konnte nicht durchgeführt werden
    4200
    Security
    Error
    Schlüssel erlaubt keinen zugelassenen Verschlüsselungsalgorithmus
    4259 Technical Warning Verschlüsselung für Zertifikat <Zertifikat> nicht möglich
    4282 Technical Error Maximalanzahl von Empfängerzertifikaten überschritten

    <=

    4.1.7.4.2 TUC_KON_071 „Daten hybrid entschlüsseln”

    TIP1-A_4617-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_071 „Daten hybrid entschlüsseln” umsetzen.

    Tabelle 171: TAB_KON_140 – TUC_KON_071 „Daten hybrid entschlüsseln“

    Element Beschreibung
    Name
    TUC_KON_071 „Daten hybrid entschlüsseln“
    Beschreibung
    Ein hybrid verschlüsseltes Dokument, das konform zu TUC_KON_070 erstellt wurde, wird entschlüsselt.
    Es muss eine asymmetrische Verschlüsselung vorliegen, zu der der Schlüssel auf einer Karte vorliegt.
    Auslöser
    Aufruf in einem fachlichen Use Case oder des Verschlüsselungsbasisdienstes.
    Vorbedingungen
    Die Karte mit dem privaten Schlüssel muss gesteckt sein und der Sicherheitszustand zur Nutzung des privaten Schlüssels muss gesetzt sein.
    Ein konform zu TUC_KON_070 hybrid verschlüsseltes Dokument liegt vor.
    Bei XML-Dokumenten: Das Dokument enthält EncryptedData Elemente. Falls mehrere Elemente des Dokumentes zu entschlüsseln sind, müssen diese alle mit demselben symmetrischen Schlüssel verschlüsselt sein.
    Eingangsdaten
    • encryptedDocument
      (Zu entschlüsselndes Dokument)
    • cardSession
      (Kartensitzung; unterstützt werden SM-B, HBAx und eGK mit der jeweiligen C.ENC-KeyReference.
    • privateKeyReference
      (Referenz auf den privaten Schlüssel; unterstützt werden SM-B, HBAx und eGK mit der jeweiligen C.ENC-KeyReference).
    • encryptionCertificate – optional
      (Verschlüsselungszertifikat passend zur Schlüsselreferenz).
    • encryptionCertificateReference – optional
      (Referenz auf das Zertifikat auf obiger Karte passend zur Schlüsselreferenz).
    • encryptedKey – optional, falls nicht in encryptedDocument enthalten ( asymmetrisch verschlüsselter symmetrischer Schlüssel)
      Darüber hinaus werden die folgenden, vom Dokumentformat und dem Verschlüsselungsverfahren abhängigen Eingangsdaten benötigt:
      Bei XML-Dokumenten:
    • xmlElements – optional/verpflichtend, wenn encryptionType = XMLEnc
      (bei XML-Dokumenten Angabe der zu entschlüsselnden Teile des XML-Dokuments)
    Komponenten
    Konnektor, Kartenterminal, Karte
    Ausgangsdaten
    • plainDocument
      (Unverschlüsseltes Dokument. Bei XML-Dokumenten: Das EncryptedData-Element ist durch das entschlüsselte ersetzt.)
    Standardablauf
    1. Das Verfahren zum Entschlüsseln wird entsprechend dem Format des übergebenen zu entschlüsselnden Dokuments (EncryptedDocument) gewählt.  
      Der Konnektor MUSS beim asymmetrischen Anteil der Entschlüsselung hybrid verschlüsselter Dokumente die in [gemSpec_Krypt] beschriebenen Verfahren unterstützen.
    2. XMLEnc:
      Das EncryptedData Element (oder mehrere Elemente) werden im Dokument lokalisiert. Falls sie nicht oder nicht eindeutig gefunden werden können wird Fehler 4103 bzw. 4104 gemeldet.
      Ist in einem EncryptedData Element ein vom Konnektor nicht unterstützter Mechanismus spezifiziert, wird Fehler 4201 gemeldet.
    3. Falls erforderlich, wird TUC_KON_216 „Lese Zertifikat“ aufgerufen, um das Zertifikat von der Karte zu lesen.
      3.1 Die Kenntnis des Zertifikats kann erforderlich sein, um im Zertifikat kodierte Verschlüsselungsparameter auszulesen. (Zur Zeit der Erstellung dieser Spezifikation werden zur Laufzeit keine zusätzlichen Parameter aus dem Zertifikat benötigt, da alle nötigen Informationen aus den PKI- und Kartenspezifikationen abgeleitet werden können.)
    4. XMLEnc:
      Es wird geprüft, ob die Verschlüsselungsparameter (EncryptionMethod in EncryptedKey) zum referenzierten privaten Schlüssel auf der Karte passen. Ist dies nicht der Fall, bricht der Use Case mit Fehler 4106 ab.
    5. Es wird TUC_KON_219 „Entschlüssele“ aufgerufen, um den symmetrischen Schlüssel mit Hilfe des angegebenen privaten Schlüssels zu entschlüsseln.
    6. Mit dem symmetrischen Schlüssel wird der unverschlüsselte Dateninhalt wiederhergestellt.
      6.1 XMLEnc: Das EncrpytedData Element wird durch die entschlüsselten Daten ersetzt.
    7. Der symmetrische Schlüssel wird aktiv gelöscht (überschrieben).
    Varianten/Alterna-
    tiven

    Zu 6.: Zur Unterstützung von Bestandssystemen werden, neben den für den symmetrischen Teil der hybriden Verschlüsselung vorgeschriebenen kryptographischen Algorithmen, für den symmetrischen Teil der hybriden Entschlüsselung auch folgende Algorithmen unterstützt (siehe [gemSpec_Krypt#3.5.1]):

    • AES-128 GCM
    • AES-192 GCM
    RSA- und ECC-basierter Hybridschlüssel:
    Wenn sowohl ein RSA- als auch ein ECC-basierter Hybridschlüssel vorliegen, muss zuerst die Entschlüsselung des ECC-basierten Hybridschlüssels erfolgen. Falls dabei ein Fehler auftritt, muss der Fehler protokolliert werden, und dann - ohne Abbruch - mit der Entschlüsselung des RSA-basierten Hybridschlüssels fortgefahren werden. 
    Fehlerfälle
    Siehe Tabelle TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“.
    Wenn im Ablauf des TUCs ein anderer Fehler als die in Tabelle TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“ beschriebenen Fehler auftritt, wird Fehler 4107 gemeldet.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    Abbildung PIC_KON_059 Aktivitätsdiagramm „Daten hybrid entschlüsseln“

    Abbildung 14: PIC_KON_059 Aktivitätsdiagramm „Daten hybrid entschlüsseln“

    Tabelle 172: TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4106
    Technical
    Error
    falscher Schlüssel
    4107
    Technical
    Error
    hybride Entschlüsselung konnte nicht durchgeführt werden
    4103
    Technical
    Error
    XML-Element nicht gefunden
    4104
    Technical
    Error
    XML-Element nicht eindeutig identifiziert
    4201
    Technical
    Error
    kryptographischer Algorithmus vom Konnektor nicht unterstützt

    <=

    4.1.7.4.3 TUC_KON_072 „Daten symmetrisch verschlüsseln”

    TIP1-A_4618

    Der Konnektor MUSS den technischen Use Case TUC_KON_072 „Daten symmetrisch verschlüsseln“ umsetzen.

    Tabelle 173: TAB_KON_741 – TUC_KON_072 „Daten symmetrisch verschlüsseln“

    Element
    Beschreibung
    Name
    TUC_KON_072 „Daten symmetrisch verschlüsseln“
    Beschreibung
    Es wird ein Dokument symmetrisch verschlüsselt. Dabei kann der zu verwendende symmetrische Schlüssel optional übergeben werden.
    Auslöser
    Aufruf durch ein Fachmodul in einem fachlichen Use Case
    Vorbedingungen
    keine
    Eingangsdaten
    • documentToBeEncrypted
      (zu verschlüsselndes Dokument.)

    • symmetricKey – optional
      (zu verwendender symmetrischer Schlüssel)

    Komponenten
    Konnektor
    Ausgangsdaten
    • encryptedDocument
      (Verschlüsseltes Dokument)

    • symmetricKey – optional/verpflichtend, wenn Schlüssel durch den TUC erzeugt wurde
      (erzeugter symmetrischer Schlüssel)

    Standardablauf
    1.       Wurde kein symmetrischer Schlüssel übergeben, so wird ein Schlüssel erzeugt. Die Qualität des Schlüssels muss den Vorgaben in [gemSpec_Krypt#2.2] genügen.
    2.       Das Dokument wird mit dem erzeugten oder übergebenen symmetrischen Schlüssel verschlüsselt.
      Als Verfahren zum Verschlüsseln wird CMS gewählt ([RFC5652]).
      Die Content Type Option „Encrypted-data Content Type“ ist zu verwenden.
      ContentType = OID{… pkcs-7   encryptedData}
                           = 1.2.840.113549.1.7.6
      Die symmetrische Verschlüsselung binärer Daten erfolgt nach den Vorgaben gemäß [gemSpec_Krypt# ].
      Falls die Verschlüsselung fehlschlägt, wird Fehler 4108 gemeldet.

    3.       Das verschlüsselte Dokument und der symmetrische Schlüssel (falls dieser erzeugt wurde) werden zurückgeliefert.
    Varianten/Alternativen
    keine
    Fehlerfälle
    Siehe Standardablauf.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 174: TAB_KON_742 Fehlercodes TUC_KON_072 „Daten symmetrisch verschlüsseln“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4108
    Technical
    Error
    Symmetrische Verschlüsselung konnte nicht durchgeführt werden

    <=

    4.1.7.4.4 TUC_KON_073 „Daten symmetrisch entschlüsseln”

    TIP1-A_4619

    Der Konnektor MUSS den technischen Use Case TUC_KON_073 „Daten symmetrisch entschlüsseln“ umsetzen.

    Tabelle 175: TAB_KON_743 - TUC_KON_073 „Daten symmetrisch entschlüsseln“

    Element
    Beschreibung
    Name
    TUC_KON_073 „Daten symmetrisch entschlüsseln”
    Beschreibung
    Es wird ein Dokument symmetrisch entschlüsselt. Der zu verwendende symmetrische Schlüssel wird übergeben.
    Auslöser
    Aufruf durch ein Fachmodul in einem fachlichen Use Case
    Vorbedingungen
    keine
    Eingangsdaten
    • encryptedDocument
      (Verschlüsseltes Dokument)

    • symmetricKey
      (zu verwendender symmetrischer Schlüssel)

    Komponenten
    Konnektor
    Ausgangsdaten
    • plainDocument
      (Entschlüsseltes Dokument)

    Standardablauf
    Das verschlüsselte Dokument wird mit dem symmetrischen Schlüssel entschlüsselt. Als Verfahren zum Entschlüsseln wird CMS gewählt ([RFC5652]).
    Das entschlüsselte Dokument wird zurückgeliefert.
    Varianten/Alterna-tiven
    keine
    Fehlerfälle
    Bei Auftreten eines Fehlers im Standardablauf wird Fehlercode 4109 gemeldet.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 176: TAB_KON_744 Fehlercodes TUC_KON_073 „Daten symmetrisch entschlüsseln“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4109
    Technical
    Error
    symmetrische Entschlüsselung konnte nicht durchgeführt werden

    <=

    4.1.7.4.5 TUC_KON_075 „Symmetrisch verschlüsseln“

    A_18001

    Der Konnektor MUSS den technischen Use Case TUC_KON_075 „Symmetrisch verschlüsseln“ umsetzen.

    Tabelle 177: TAB_KON_860 – TUC_KON_075 „Symmetrisch verschlüsseln“

    Element
    Beschreibung
    Name
    TUC_KON_075 „Symmetrisch verschlüsseln“
    Beschreibung
    Es werden binäre Daten symmetrisch verschlüsselt. Optional können der zu verwendende symmetrische Schlüssel und AssociatedData für Authenticated Encryption with Associated Data (AEAD) übergeben werden.
    Auslöser
    Aufruf durch ein Fachmodul in einem fachlichen Use Case
    Vorbedingungen
    keine
    Eingangsdaten
    • dataToBeEncrypted
      (zu verschlüsselnde Daten)
    • symmetricKey – optional
      (zu verwendender symmetrischer Schlüssel)
    • associatedData - optional
      (Parameter für den Verschlüsselungsalgorithmus)
    Komponenten
    Konnektor
    Ausgangsdaten
    • encryptedData
      (Verschlüsselte Daten mit der Struktur gemäß Punkt 2 aus )
    • symmetricKey – optional/verpflichtend, wenn Schlüssel durch den TUC erzeugt wurde
      (erzeugter symmetrischer Schlüssel)
    Standardablauf
    1. Wurde kein symmetrischer Schlüssel übergeben, so wird ein Schlüssel erzeugt. Die Qualität des Schlüssels muss den Vorgaben in  genügen.
    2. dataToBeEncrypted wird mit dem erzeugten oder übergebenen symmetrischen Schlüssel unter Berücksichtigung der optional übergebenen associatedData verschlüsselt.
      Die symmetrische Verschlüsselung binärer Daten erfolgt nach den Vorgaben gemäß .
    3. encryptedData wird erzeugt mit der Struktur gemäß Punkt 2 aus .
    4. Das verschlüsselte Dokument und der symmetrische Schlüssel (falls dieser erzeugt wurde) werden zurückgeliefert.
    Varianten/Alternativen
    keine
    Fehlerfälle
    -> 2: Falls die Verschlüsselung fehlschlägt, wird Fehler 4108 gemäß TAB_KON_742 gemeldet.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    <=

    4.1.7.4.6 TUC_KON_076 „Symmetrisch entschlüsseln“

    A_18002

    Der Konnektor MUSS den technischen Use Case TUC_KON_076 „Symmetrisch entschlüsseln“ umsetzen.

    Tabelle 178: TAB_KON_861 - TUC_KON_076 „Symmetrisch entschlüsseln“

    Element
    Beschreibung
    Name
    TUC_KON_076 „Symmetrisch entschlüsseln”
    Beschreibung
    Es werden verschlüsselte Daten symmetrisch entschlüsselt. Für Authenticated Encryption with Associated Data (AEAD) kann AssociatedData optional übergeben werden. Der zu verwendende symmetrische Schlüssel wird übergeben.
    Auslöser
    Aufruf durch ein Fachmodul in einem fachlichen Use Case
    Vorbedingungen
    keine
    Eingangsdaten
    • encryptedData
      (Verschlüsselte Daten mit der Struktur gemäß Punkt 2 aus )
    • symmetricKey
      (zu verwendender symmetrischer Schlüssel)
    • associatedData - optional
      (Parameter für den Verschlüsselungsalgorithmus)
    Komponenten
    Konnektor
    Ausgangsdaten
    • plainData
      (Entschlüsselte Daten)
    Standardablauf
    Das verschlüsselte Dokument wird mit dem symmetrischen Schlüssel und associatedData unter Verwendung der kryptographischen Verfahren aus   entschlüsselt.
    Die entschlüsselten Daten werden zurückgeliefert.
    Varianten/Alterna-tiven
    keine
    Fehlerfälle
    Bei Auftreten eines Fehlers im Standardablauf wird Fehlercode 4109 gemäß TAB_KON_744 gemeldet.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine
    <=

    4.1.7.5 Operationen an der Außenschnittstelle

    TIP1-A_4620-03

    Der Konnektor MUSS für Clients einen Basisdienst Verschlüsselungsdienst anbieten.

    Tabelle 179: TAB_KON_745 Basisdienst Verschlüsselungsdienst

    Name
    EncryptionService
    Version (KDV)
    6.1.0 (WSDL-Version), 6.1.1 (XSD-Version)
    6.1.1 (WSDL-Version), 6.1.2 (XSD-Version)

    Namensraum
    Siehe GitHub
    Namensraum-Kürzel
    CRYPT für Schema und CRYPTW für WSDL
    Operationen
    Name
    Kurzbeschreibung
    EncryptDocument
    Dokument hybrid verschlüsseln
    DecryptDocument
    Dokument hybrid entschlüsseln
    WSDL
    EncryptionService.wsdl (WSDL-Version 6.1.0)
    EncryptionService_v6_1_1.wsdl

    Schema
    EncryptionService.xsd (XSD-Version 6.1.1)
    EncryptionService_v6_1_2.xsd


    <=

    4.1.7.5.1 EncryptDocument

    TIP1-A_4621-05

    Der Basisdienst Verschlüsselungsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation EncryptDocument anbieten.

    Tabelle 180: TAB_KON_071 Operation EncryptDocument

    Name
    EncryptDocument
    Beschreibung
    Diese Operation verschlüsselt ein übergebenes Dokument hybrid.
    Es werden die Dokumententypen Alle_DocFormate unterstützt.
    Für die hybride Verschlüsselung wird ein asymmetrischer Schlüssel aus einem X.509v3-Zertifikat genutzt. Dieses Zertifikat kann von einer Karte kommen oder als Parameter übergeben werden. Pro Operationsaufruf können mehrere Hybridschlüssel erzeugt werden. 
    Übergibt der Aufrufer die Zertifikate beim Aufruf, steuert er durch die Wahl der Zertifikate, ob RSA-basierte oder ECC-basierte Hybridschlüssel erzeugt werden. Wenn das Verschlüsselungszertifikat von einer Karte kommt, kann der Aufrufer durch Angabe des Kryptoverfahrens crypt steuern, ob Hybridschlüssel für RSA oder für ECC oder beide erzeugt werden. Das Defaultverhalten ist die Hybridschlüsselerzeugung für RSA und entspricht dem Verhalten aus der Version 6.1.0 der Schnittstelle.
    Es werden die folgenden Karten unterstützt: HBAx und SM-B. Die Operation EncryptDocument DARF das Verschlüsseln mit der eGK NICHT unterstützen.
    Für alle Dokumenttypen wird immer das gesamte Dokument verschlüsselt.
    Vom Konnektor zu verschlüsselnde Dokumente müssen konform zu den Anforderungen in Kapitel 3.1.1 "Dokumentformate" sein.





    Name
    Beschreibung
    Context
    Aufrufkontext:
    • MandantID, ClientSystemID, WorkplaceId verpflichtend
    • UserID verpflichtend bei HBAx, bei SM-B nicht ausgewertet






    Das RecipientKeys-Element identifiziert die Empfänger der zu verschlüsselnden Nachricht über X.509-Zertifikate (öffentliche Schlüssel). Quelle für die Zertifikate kann eine gesteckte Karte sein, die per CertificateOnCard-Element referenziert wird, oder der Aufrufer, der X.509-Zertifikate im Certificate-Element übergibt.
    Card
    Handle
    Identifiziert die zu verwendende Karte mit dem (öffentlichen) Schlüssel.
    Ist das Element nicht vorhanden, so werden nur Zertifikate per Element Certificate übergeben.
    KeyRef
    erence
    Der Wert dieses Parameters ist in Tabelle TAB_KON_747 KeyReference für Encrypt-/DecryptDocument spezifiziert. Ist der Parameter nicht angegeben, gilt der Default-Wert C.ENC.
    Crypt
    Optional; 
    Default: siehe TAB_KON_859
    Wertebereich: [ENC_CRYPT]
    Gibt den Typ von Zertifikaten vor, die von der per CardHandle referenzierten Karte für die Erzeugung der Hybridschlüssel gemäß Tabelle TAB_KON_747 verwendet werden.
    Certifi
    cate
    Certificate ist ein Base64-kodiertes XML-Element, in dem das Zertifikat, das den asymmetrischen Schlüssel enthält (öffentlicher Schlüssel), DER-kodiert übergeben wird.
    Es kann eine Liste von Zertifikaten übergeben werden. Der Konnektor MUSS eine Liste von mindestens 1000 Zertifikaten unterstützen.
    Kommt das Zertifikat ausschließlich von einer Karte, dann kann dieser Parameter weggelassen werden.
    CONN:
    Document
    Dieses entsprechend [OASIS-DSS] Section 2.4.2 spezifizierte Element enthält das zu verschlüsselnde Dokument, wobei die Kindelemente CONN:Base64XML und dss:Base64Data verwendet werden. Im Fall dss:Base64Data wird ein etwaig übergebenes MIME-Type-Attribut nicht ausgewertet.
    CRYPT:
    Optional
    Inputs
    Enthält eine Auswahl der folgenden unten näher erläuterten (optionalen) Eingabeparameter:
    Encryption
    Type
    Zu wählendes Verschlüsselungsverfahren, wobei folgende URI vorgesehen sind:
    • XMLEnc: „http://www.w3.org/TR/xmlenc-core/”
    • CMS: „urn:ietf:rfc:5652“
    • S/MIME: „urn:ietf:rfc:5751”
    Im Fall XMLEnc wird ein Base64-codiertes XML-Dokument im Element CONN:Document/CONN:Base64XML übergeben.
    In den Fällen CMS und S/MIME wird ein Base64-codiertes Binär-Dokument im Element CONN:Document/dss:Base64Data übergeben .
    Ist der Parameter EncryptionType nicht gesetzt, dann gilt folgendes Default-Verhalten: Für ein im Element CONN:Document/CONN:Base64XML übergebenes XML-Dokument wird als Verschlüsselungsverfahren [XMLEnc] angewandt, und für ein im Element CONN:Document/dss:Base64Data übergebenes Dokument wird das Verschlüsselungsverfahren CMS angewandt.
    XML-Documente werden nach Type=http://www.w3.org/2001/04/xmlenc#Element verschlüsselt. Im Fall S/MIME ist das in CONN:Document/dss:Base64Data übergebene Dokument eine MIME-Nachricht.
    Der Konnektor KANN die Operation im Fall S/MIME mit Fehlercode 4279 beenden.

    Element
    Der Parameter wird nicht ausgewertet.




    CRYPT:
    Unprotected
    Properties
    Dieses optionale Element wird im CMS-Fall (EncryptionType = urn:ietf:rfc:5652) ausgewertet.    
    Die Elemente ./UnprotectedProperties/Property/Value/CMSAttribute müssen base64/DER-kodiert ein vollständiges ASN.1-Attribute enthalten, definiert in [CMS# 9.1.AuthenticatedData Type]. Es muss bei der Erstellung des CMS-Containers unter "unauthAttrs" aufgenommen werden. Das zugehörige Element ./UnprotectedProperties/Property/Identifier wird nicht ausgewertet.
    Rückgabe
    Status
    Enthält den Ausführungsstatus der Operation.
    CRYPT:
    Optional
    Outputs
    Kann – in zukünftigen Versionen der Spezifikation – optionale Ausgabeparameter enthalten.
    CONN:
    Document
    Enthält das verschlüsselte Dokument in base64-codierter Form, wenn die Verschlüsselung erfolgreich durchgeführt wurde.
    Im Fall XMLEnc wird das Base64-codierte verschlüsselte XML-Dokument im Element CONN:Document/CONN:Base64XML zurückgegeben.
    Im Fall CMS wird das Base64-codierte Binär-Dokument im Element CONN:Document/dss:Base64Data zurückgegeben.
    Im Fall S/MIME wird die Base64-codierte S/MIME-Nachricht im Element CONN:Document/dss:Base64Data zurückgegeben. Das Attribut CONN:Document/dss:Base64Data/@MimeType wird auf „application/pkcs7-mime“ gesetzt. Die S/MIME-Nachricht hat Content-Transfer-Encoding: base64.
    Fehler
    Bei Auftreten eines Fehlers im Standardablauf werden Fehlercodes entsprechend TAB_KON_141 gemeldet.
    Vorbe-dingungen
    Keine
    Nachbe-dingungen
    Keine


    Der Ablauf der Operation EncryptDocument ist in Tabelle TAB_KON_746 Ablauf EncryptDocument beschrieben:

    Tabelle 181: TAB_KON_746 Ablauf EncryptDocument

    Nr.

    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung

    1.


    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab. Wird die Operation für einen nicht unterstützten Kartentypen aufgerufen, so bricht die Operation mit Fehler 4058 ab.
    2. checkDocumentFormat Der Konnektor prüft für das zu verschlüsselnde Dokument, ob die Vorgaben aus Kapitel 3.1.1 eingehalten sind. Bei Verletzung einer Vorgabe bricht der Konnektor die Verarbeitung mit einem entsprechenden Fehlercode ab.
    3.


    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle = $cardHandle }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    4.


    TUC_KON_026 „Liefere CardSession“

    Ermittle CardSession über TUC_KON_026 {
        mandatId =$context..mandantId;
        clientSystemId = $context.clientSystemId;
        cardHandle = $context..cardHandle;
        userId = $context.userId }
    5.


    TUC_KON_070 „Daten hybrid verschlüsseln“

    Die hybride Verschlüsselung wird durchgeführt. Tritt hierbei ein Fehler auf, bricht die Operation ab.
    Die KeyInfo, d.h. die Liste der Hybridschlüssel inklusive des bei ihrer Erzeugung verwendeten Zertifikates, sind dabei in das Dokument einzubetten.

    Tabelle 182: TAB_KON_141 Fehlercodes „EncryptDocument“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases und Fehlercodes aus Kapitel 3.1.1 können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4001
    Security
    Error
    Interner Fehler
    4058
    Security
    Error
    Aufruf nicht zulässig
    4279 Technical Error S/MIME-Funktionalität nicht unterstützt"
    4283 Technical Error Dokument zu groß
    <=

    4.1.7.5.2 DecryptDocument

    TIP1-A_4622-05

    Der Basisdienst Verschlüsselungsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation DecryptDocument anbieten.

    Tabelle 183: TAB_KON_075 Operation DecryptDocument

    Name
    DecryptDocument
    Beschreibung
    Die Operation entschlüsselt alle hybrid verschlüsselten Dokumente, die mit der Operation EncryptDocument erzeugt wurden. Es werden die Dokumententypen Alle_DocFormate unterstützt.
    Für die Entschlüsselung wird ein asymmetrischer Schlüssel zu einem X.509v3-Zertifikat genutzt. Dieses Zertifikat und der Schlüssel müssen von einer Karte kommen.
    Das bei der Entschlüsselung verwendete Kryptoverfahren (RSA oder ECC) wird durch den Hybridschlüssel bestimmt, der durch die Karte entschlüsselt werden soll. Sind sowohl RSA- als auch ECC-Hybridschlüssel für die referenzierte Karte vorhanden, versucht der Konnektor die Entschlüsselung des ECC-Hybridschlüssels, und wenn das nicht erfolgreich war, die Entschlüsselung des RSA-Hybridschlüssels.
    Vom Konnektor zu entschlüsselnde Dokumente müssen konform zu den Anforderungen in Kapitel 3.1.1 "Dokumentformate" sein.
    Aufrufparameter


    Name
    Beschreibung
    Context
    Aufrufkontext:
    • MandantId, ClientSystemId, WorkplaceId verpflichtend
    • UserId verpflichtend bei HBAx, bei SM-B nicht ausgewertet



    PrivateKey
    OnCard
    Identifiziert die zu verwendende Karte mit dem (privaten) Schlüssel.
    Es werden die folgenden Karten unterstützt: HBAx und SM-B. Die Operation DecryptDocument DARF das Entschlüsseln mit der eGK NICHT unterstützen.
    CardHandle
    Identifiziert die gesteckte Karte.
    KeyReference
    Der Wert dieses Parameters ist in der Tabelle TAB_KON_747 KeyReference für Encrypt-/DecryptDocument spezifiziert. Ist der Parameter nicht angegeben, gilt der Default-Wert C.ENC.
    Crypt
    Ist nicht enthalten.
    CONN:
    Document
    Enthält das base64-codierte Dokument, das entschlüsselt werden soll.
    CRYPT:
    OptionalInputs
    Kann – in zukünftigen Versionen der Spezifikation – optionale Aufrufparameter enthalten.
    Rückgabe


    Status
    Enthält den Ausführungsstatus der Operation.
    CRYPT:
    OptionalOutputs
    Kann – in zukünftigen Versionen der Spezifikation – optionale Ausgabeparameter enthalten.
    CONN:Document
    Enthält das entschlüsselte Dokument in base64-codierter Form
    Fehler
    Bei Auftreten eines Fehlers im Standardablauf werden Fehlercodes entsprechend TAB_KON_145 gemeldet.
    Vorbe-dingungen
    Keine
    Nachbe-dingungen
    Keine

    Der Ablauf der Operation DecryptDocument ist in Tabelle TAB_KON_076 Ablauf DecryptDocument beschrieben:

    Tabelle 184: TAB_KON_076 Ablauf DecryptDocument

    Nr.
    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung
    1.

    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab. Wird die Operation für einen nicht unterstützten Kartentypen aufgerufen, so bricht die Operation mit Fehler 4058 ab.
    2.

    TUC_KON_000 „Prüfe Zugriffs- berechtigung“
    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle = $cardHandle }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3.

    TUC_KON_026 „Liefere CardSession“
    Ermittle CardSession über 026 {
        mandatId =$context.mandantId;
        clientsystemId  = $context.clientsystemId;
        cardHandle = $context.cardHandle;
        userId = $context.userId }
    4.

    TUC_KON_071 Daten hybrid entschlüsseln
    Die Entschlüsselung wird durchgeführt.
    Im Fall eines XML-Dokuments mit mehreren verschlüsselten Elementen sind alle mit dem angegebenen Schlüssel entschlüsselbaren Elemente zu entschlüsseln.
    Wenn für das entschlüsselte Dokument Vorgaben aus Kapitel 3.1.1 nicht eingehalten sind, bricht der Konnektor die Verarbeitung mit einem entsprechenden Fehlercode ab.
    Im Fall eines MIME-Dokuments KANN der Konnektor die Operation mit Fehlercode 4279 beenden.

    Tabelle 185: TAB_KON_145 Fehlercodes „DecryptDocument“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases und Fehlercodes aus Kapitel 3.1.1 können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4001
    Security
    Error
    interner Fehler
    4058
    Security
    Error
    Aufruf nicht zulässig
    4279 Technical Error S/MIME-Funktionalität nicht unterstützt
    4283 Technical Error Dokument zu groß
    <=

    4.1.7.6 Betriebsaspekte

    keine

    4.1.8 Signaturdienst

    Der Signaturdienst bietet Clientsystemen und Fachmodulen eine Schnittstelle zum Signieren von Dokumenten und Prüfen von Dokumentensignaturen

    Innerhalb des Signaturdienstes werden folgende Präfixe für Bezeichner verwendet:

    4.1.8.1 Funktionsmerkmalweite Aspekte
    4.1.8.1.1 Dokumentensignatur

    Der Signaturdienst umfasst die Funktionalität der nicht-qualifizierten elektronischen Signatur (nonQES) mit der SM-B, sowie die qualifizierte elektronische Signatur (QES) mit dem HBA und den HBA-Vorläuferkarten HBA-qSig und ZOD_2.0 (=HBAx).

    In der Abbildung fachlicher Abläufe kann es nötig sein, ein Dokument mehrfach parallel zu signieren, oder existierende Signaturen gegenzusignieren. Der Konnektor unterstützt parallele Signaturen (QES und nonQES). Ebenso unterstützt er Gegensignaturen (QES und nonQES), die jeweils alle bestehenden Signaturen gegensignieren. Die angebotene Möglichkeit des Gegensignierens bezieht sich dabei auf das Signieren aller vorhandenen parallelen Signaturen, während ein Gegensignieren von Gegensignaturen nicht angeboten wird. Der Konnektor unterstützt ausschließlich eine dokumentexkludierende Gegensignatur, bei der alle Signaturen gegensigniert werden, aber nicht der fachliche Inhalt des Dokumentes selbst.

    TIP1-A_4623-02

    Der Signaturdienst MUSS für die Erstellung und Prüfung von nicht-qualifizierten elektronischen Signaturen (nonQES) für die nonQES_DocFormate die Signaturverfahren entsprechend Tabelle TAB_KON_582 – Signaturverfahren unterstützen.
    <=

    TIP1-A_4627

    Der Signaturdienst MUSS für die Erstellung und Prüfung von qualifizierten elektronischen Signaturen (QES) für die QES_DocFormate die Signaturverfahren entsprechend Tabelle TAB_KON_582 – Signaturverfahren unterstützen.
    <=

    Tabelle 186: TAB_KON_582 – Signaturverfahren Dokumentensignatur

    Signaturformat
    Standard
    Dokumentformate
    QES/
    nonQES
    Bemerkung
    XMLDSig
    (XAdES)
    [RFC3275]
    [XMLDSig]
    [XAdES]
    [RFC6931]
    XML
    QES,
    nonQES
    Hierdurch können abgesetzte (detached), umschließende (enveloping) und eingebettete (enveloped) Signaturen erzeugt werden.
    CMS
    (CAdES)
    [RFC5652]
    [CAdES]
    QES_DocFormate
    nonQES_DocFormate

    QES,
    nonQES
    Hierdurch können abgesetzte (detached) und umschließende (enveloping) Signaturen erzeugt werden.
    PDF/A
    (PAdES)
    [PAdES-3]
    PDF/A
    QES,
    nonQES
    Hierdurch können CMS-basierte Signaturen in PDF/A-Dokumente eingefügt und dadurch eingebettete Signaturen erzeugt werden.
    S/MIME
    (optional)
    [RFC5751]
    nonQES_DocFormate
    nonQES
    Optional wird die Signatur und Signaturprüfung von MIME-Nachrichten unterstützt.
    Der Konnektor soll, wenn er die S/MIME-Signatur unterstützt, auch die S/MIME-Signaturprüfung unterstützen.

    Zu den Begriffen detached, enveloping und enveloped Signaturen siehe beispielsweise auch [HüKo06#Abs. 4.3.3. und 4.3.1.5].

    TIP1-A_5447

    Der Signaturdienst MUSS für die Erstellung und Prüfung von nicht-qualifizierten elektronischen Signaturen (nonQES) und qualifizierten elektronischen Signaturen (QES) die Vorgaben zum Einsatzbereich gemäß Tabelle TAB_KON_778 umsetzen.

    Tabelle 187: TAB_KON_778 – Einsatzbereich der Signaturvarianten für XAdES, CAdES und PAdES

    Signaturvarianten
    Einsatzbereich
    Signatur
    verfahren
    Signatur-
    variante
    WAS wird signiert?
    WO wird die Signatur abgelegt?
    nonQES
    QES
    Außen-
    schnittstelle
    QES
    Fachmodul-
    schnittstelle
    XAdES
    detached
    beliebiges (Binär)-Dokument
    außerhalb des Dokuments in der SignResponse
    Nein
    Nein
    Nein
    XAdES
    detached
    gesamtes Input XML-Dokument
    (= Root-Element mit Subelementen)
    außerhalb des Dokuments in der SignResponse
    Nein
    Nein
    Nein
    XAdES
    detached
    ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument
    außerhalb des Dokuments in der SignResponse
    Nein
    Nein
    Nein
    XAdES
    detached
    ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument
    Innerhalb des Dokuments, aber außerhalb des signierten Subbaums
    Nein
    Bedingt
    Bedingt
    XAdES
    enveloped
    gesamtes Input XML-Dokument
    (= Root-Element mit Subelementen)
    Als direktes Child des Root-Elements
    Ja
    Bedingt
    Bedingt
    XAdES
    enveloped
    ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument
    Als direktes Child des ausgewählten Elements
    Nein
    Nein
    Bedingt
    XAdES
    enveloping
    gesamtes Input XML-Dokument
    (= Root-Element mit Subelementen)
    Im Dokument, das Root-Element umschließend
    Ja
    Bedingt
    Bedingt
    XAdES
    enveloping
    ausgewähltes nicht Root-Element mit Subelementen im Input XML-Dokument
    Im Dokument, das ausgewählte Element umschließend
    Nein
    Nein
    Nein
    CAdES
    detached
    gesamtes Binärdokument
    außerhalb des Dokuments in der SignResponse
    Ja
    Ja
    Ja
    CAdES
    enveloping
    gesamtes Binär-Dokument
    innerhalb des CMS-Dokuments
    Ja
    Ja
    Ja
    PAdES
    -
    gesamtes PDF-Dokument
    Im PDF-Dokument
    Ja
    Ja
    Ja
    Legende:
    Ja: Die Signaturvariante ist für den Einsatzbereich erlaubt.
    Nein: Die Signaturvariante ist für den Einsatzbereich nicht erlaubt.
    Bedingt: Die Signaturvariante ist für den Einsatzbereich nicht erlaubt, es sei denn es wird durch eine im Konnektor integrierte Signaturrichtlinie explizit gefordert.
    Die Spalten mit gelber Kopfzeile definieren die Signaturvarianten, die mit grauer, den Einsatzbereich. Beim Einsatzbereich wird zwischen nonQES und QES unterschieden und im Fall QES nach der Bereitstellung an der Außenschnittstelle oder intern für Fachmodule.
    Die benötigten Signaturvarianten werden für XAdES über die Aufrufparameter IncludeObject und SignaturePlacement gemäß [OASIS-DSS] gesteuert.
    Für CAdES erfolgt die Steuerung welche Signaturvariante gewählt wird, über den Aufrufparameter IncludeEContent.
    <=

    A_18756

    Der Konnektor KANN alle Aufrufe zu Signaturerstellung einer nonQES-XAdES Signatur mit Fehler 4111 und alle Aufrufe zur Signaturprüfung einer nonQES-XAdES Signatur mit Fehler 4112 beantworten. Die Signaturvarianten aus TAB_KON_778 werden damit weiter eingeschränkt. Wird die nonQES-XAdES Signatur umgesetzt, so ist diese in der Sicherheitszertifizierung zu betrachten. <=

    TIP1-A_5402

    Der Konnektor MUSS von den AdES-Profilen die AdES-EPES-Profile umsetzen, ergänzt um

    Dabei MUSS der Konnektor die Baseline-Profilierung gemäß Kapitel 6 in [XAdES Baseline Profile] für XAdES, Kapitel 6 in [CAdES Baseline Profile] für CAdES und Kapitel 6 in [PAdES Baseline Profile] für PAdES umsetzen.

    <=

    Durch die Baseline-Profilierung der AdES-BES-Profile wird festgelegt, wie der Signaturzeitpunkt, gemessen als Systemzeit des Konnektors, in die Signatur eingebracht wird.

    TIP1-A_5403

    Der Konnektor SOLL die signierten Dokumente konform zu [COMMON_PKI#Part 3] und [COMMON_PKI#Part 8] erstellen.

    <=

    TIP1-A_4624

    Bei fehlender expliziter Angabe durch den Aufrufer MUSS der Signaturdienst bei der Erstellung von nicht-qualifizierten elektronischen Signaturen (nonQES) die Default-Signaturverfahren entsprechend TAB_KON_583 Default-Signaturverfahren wählen.

    <=

    TIP1-A_4628

    Bei fehlender expliziter Angabe durch den Aufrufer MUSS der Signaturdienst bei der Erstellung von qualifizierten elektronischen Signaturen (QES) die Default-Signaturverfahren entsprechend TAB_KON_583 – Default-Signaturverfahren wählen.

    <=

    Tabelle 188: TAB_KON_583 – Default-Signaturverfahren

    Dokument-Format
    Signaturverfahren (und -variante)
    Signaturverfahren
    Signaturvariante
    WAS wird signiert?
    WO wird die Signatur abgelegt?
    XML
    XAdES
    enveloped
    gesamtes Input XML-Dokument
    (= Root-Element mit Subelementen)
    als direktes Child des Root-Elements
    PDF/A
    PAdES
    -
    gesamtes PDF-Dokument
    im PDF-Dokument
    alle anderen
    CAdES
    detached
    gesamtes Binärdokument
    außerhalb des Dokuments in der SignResponse

    TIP1-A_5387

    Der Konnektor MUSS auf eine vollständige Nutzung der AdES-Profile erweiterbar sein.

    <=

    TIP1-A_5033

    Der Konnektor MUSS zur Unterstützung von Missbrauchserkennungen die in Tabelle TAB_KON_584 gelisteten Operationen als Einträge in EVT_MONITOR_OPERATIONS berücksichtigen.

    Tabelle 189: TAB_KON_584 nonQES-Operationen für EVT_MONITOR_OPERATIONS

    Operationsname
    OK_Val
    NOK_Val
    Alarmwert (Default-Grenzwert 10 Minuten-Σ)
    SignDocument (nonQES)
    1
    5
    41
    VerifyDocument (nonQES)
    1
    5
    61

    <=

    TIP1-A_4629

    Der Signaturdienst MUSS für die QES-Erstellung die Kartentypen HBA, HBA-qSig und ZOD_2.0 unterstützen.

    <=

    TIP1-A_5436

    Der Konnektor MUSS die Operation SignDocument für XML-Dokumente so implementieren, dass das Dokument nach Entfernen der Signatur, insbesondere auch einer Teilsignatur, als Ganzes unverändert ist, wobei zwei XML-Dokumente als identisch zu betrachten sind, wenn sie gemäß Canonical XML 1.1 gleich sind [CanonXML1.1].

    <=

    TIP1-A_5682

    Der Konnektor MUSS im VerificationReport einer QES-Signaturprüfung ausweisen, wenn die für die Signatur verwendeten Algorithmen nach dem Algorithmenkatalog [ALGCAT] als nicht geeignet eingestuft werden.
    <=

    A_17768

    Der Konnektor MUSS bei der Signaturerstellung und Signaturprüfung (QES und nonQES) die Zertifikate und Schlüssel gemäß den Vorgaben in TAB_KON_900 ermitteln.

    Tabelle 190: TAB_KON_900 Zertifikate und private Schlüssel für Signaturerstellung und Signaturprüfung (QES und nonQES)

     Karte
     
    Crypt
     
    Zertifikat (Verify)

    Schlüssel (Sign)

    Einsatzbereich
    Außen-schnittstelle Fachmodul-schnittstelle
    QES ...in DF.QES
    HBA RSA EF.C.HP.QES.R2048 PrK.HP.QES.R2048 ja ja
    ECC EF.C.HP.QES.E256 PrK.HP.QES.E256 ja ja
    RSA_ECC [ab G2.1]: EF.C.HP.QES.E256
    [G2.0]: EF.C.HP.QES.R2048
    [ab G2.1]: PrK.HP.QES.E256
    [G2.0]: PrK.HP.QES.R2048
    ja ja
    HBA-VK RSA EF.C.HP.QES PrK.HP.QES ja ja
    nonQES ...in DF.ESIGN
    SM-B RSA EF.C.HCI.OSIG.R2048 PrK.HCI.OSIG.R2048 ja ja
    ECC EF.C.HCI.OSIG.E256 PrK.HCI.OSIG.E256 ja ja
    RSA_ECC [ab G2.1]: EF.C.HCI.OSIG.E256
    [G2.0]: EF.C.HCI.OSIG.R2048
    [ab G2.1]: PrK.HCI.OSIG.E256
    [G2.0]: PrK.HCI.OSIG.R2048
    ja ja
    eGK RSA EF.C.CH.AUT.R2048 PrK.CH.AUT.R2048 nein ja
    ECC EF.C.CH.AUT.E256 PrK.CH.AUT.E256 nein ja
    RSA_ECC [ab G2.1]: EF.C.CH.AUT.E256
    [G2.0]: EF.C.CH.AUT.R2048
    [ab G2.1]: PrK.CH.AUT.E256
    [G2.0]: PrK.CH.AUT.R2048
    nein ja
    <=

    Tabelle 191: TAB_KON_862-01 Werteliste und Defaultwert des Parameters crypt bei QES-Erzeugung

    Typname
    Werteliste
    Defaultwert
    Bedeutung
    SIG_CRYPT_QES
    RSA
    ECC
    RSA_ECC
    RSA
    Werteliste des Parameters crypt bei der bei der Erzeugung einer QES-Signatur
    RSA: Es wird eine RSA-2048 Signatur erzeugt.
    ECC: Es wird eine ECC-256 Signatur erzeugt.
    RSA_ECC: In Abhängigkeit von der Kartengeneration wird eine RSA-2048 bzw. eine ECC-256 Signatur erzeugt (siehe TAB_KON_900).

    Tabelle 192: TAB_KON_863 Werteliste und Defaultwert des Parameters crypt bei nonQES-Erzeugung

    Typname
    Werteliste
    Defaultwert
    Bedeutung
    SIG_CRYPT_nonQES
    RSA
    ECC
    RSA_ECC
    RSA
    Werteliste des Parameters crypt bei der bei der Erzeugung einer nonQES-Signatur
    RSA: Es wird eine RSA-2048 Signatur erzeugt.
    ECC: Es wird eine ECC-256 Signatur erzeugt.
    RSA_ECC: In Abhängigkeit von der Kartengeneration wird eine RSA-2048 bzw. eine ECC-256 Signatur erzeugt (siehe TAB_KON_900).

    4.1.8.1.2 Signaturrichtlinien

    Signaturrichtlinien dienen der Profilierung von Signaturerstellung und -prüfung. Beim Aufruf der Operation SignDocument kann eine URI übergeben werden, die eine im Konnektor hinterlegte Signaturrichtlinie referenziert. Die Plattform des Konnektors stellt selbst keine Signaturrichtlinien bereit. Fachanwendungen, die Signaturrichtlinien erfordern, definieren diese im Fachmodul des Konnektors. Für XML-Dokumentenformate aus der Menge von QES_DocFormate können die nachfolgenden Aspekte über eine Signaturrichtlinie gekapselt festgelegt werden:

    TIP1-A_5538

    Der Konnektor MUSS Signaturrichtlinien für XML-Dokumentenformate aus der Menge von QES_DocFormate bei die Signaturerstellung und -prüfung umsetzen.

    Der Konnektor MUSS den für jede Signaturrichtlinie definierten Bezeichner (URI) bei der Signatur als SigPolicyId im Feld SignaturePolicyIdentifier einbetten. Bei der Signaturprüfung MUSS der Konnektor über eine etwaig vorhandene SigPolicyId die Signaturrrichtlinie identifizieren.

    Die gemäß AdES erforderliche Hash-Referenz über die Policy (SigPolicyHash) MUSS Schema-konform leer gelassen werden. Bei der Signaturprüfung DARF die Hash-Referenz über die Policy NICHT geprüft werden.

    <=

    4.1.8.1.3 Signaturzeitpunkt

    Bezogen auf den vom Konnektor für die Signaturprüfung anzunehmenden Signaturerstellungszeitpunkt werden in dieser Spezifikation die Bezeichner Ermittelter_Signaturzeitpunkt und Benutzerdefinierter_Zeitpunkt verwendet.

    Ermittelter_Signaturzeitpunkt: Vom Konnektor ermittelter Zeitpunkt, zu dem eine Signatur geprüft wird. Es werden folgende Signaturzeitpunkte ermittelt:

    1. Ermittelter_Signaturzeitpunkt_Eingebettet:
      in der Signatur eingebetteter Zeitpunkt (falls vorhanden)
    2. Ermittelter_Signaturzeitpunkt_System:
      Systemzeit des Konnektors bei Signaturprüfung

    Anmerkung: Bei vom Konnektor selbst erstellten Signaturen ist immer ein in der Signatur eingebetteter Zeitpunkt vorhanden, jedoch kein qualifizierter Zeitstempel, da in der TI keine qualifizierten Zeitstempel ausgestellt werden. Sollte ein Dokument mit einem qualifizierten Zeitstempel versehen sein, so wird dieser nicht für die Ermittlung des Signaturzeitpunktes herangezogen.

    Benutzerdefinierter_Zeitpunkt: Vom Benutzer beim Aufruf der Signaturprüfoperation als Parameter an den Konnektor übergebener Zeitpunkt, zu dem eine Signatur geprüft werden soll.

    4.1.8.1.4 Jobnummer

    Da die eHealth-Kartenterminals dezentral über eine Netzwerkschnittstelle am Konnektor betrieben werden, fehlt die Möglichkeit zur direkten physischen und vom Anwender kontrollierbaren Zuordnung eines solchen Terminals zu einem Arbeitsplatz, auf dem sich das Clientsystem befindet.

    Daher ist es bei einer fehlerhaften Zuordnung eines eHealth-Kartenterminals zu einem Arbeitsplatz möglich, dass die PIN-Eingabeaufforderung – beispielsweise zu einem Signaturauftrag – an ein entferntes Kartenterminal weitergeleitet wird. Diese fehlerhafte Zuordnung kann durch einen Fehler des Clientsystems oder den Versuch eines Angriffes hervorgerufen werden.

    Die Jobnummern werden vom Konnektor erzeugt und können durch Clientsystem abgerufen werden. Der Konnektor stellt jedoch keine Verbindung zwischen erzeugten und verwendeten Jobnummern her. Es wird also nicht geprüft, ob nur Jobnummern verwendet werden, die vorher vom Konnektor erzeugt wurden, oder ob alle Jobnummern verwendet werden, die vom Konnektor erzeugt wurden.

    TIP1-A_4639

    Um Fehler- und Angriffsmöglichkeiten auszuschließen, MUSS der Konnektor bei bestimmten PIN-Verifikationen vor der Aufforderung zur PIN-Eingabe an einem eHealth-Kartenterminal eine hinreichend eindeutige Nummer – die Jobnummer – generieren, welche den Auftrag kennzeichnet, für dessen Verarbeitung die PIN-Eingabe erfolgen soll. Bei welchen PIN-Verifikationen dies der Fall ist, kann den PIN-Prompts in TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal entnommen werden.
    <=

    TIP1-A_4640

    Diese Jobnummer MUSS vom Konnektor im Display des eHealth-Kartenterminals neben der PIN-Eingabeaufforderung angezeigt werden.

    <=

    TIP1-A_4992-02

    Das Handbuch des Konnektors MUSS den Benutzer über den korrekten Gebrauch der Jobnummer informieren. Es MUSS ihm verdeutlichen, dass er seine PIN über die Tastatur des eHealth-Kartenterminals nur eingeben darf, wenn am Primärsystem und am Display des Kartenterminals die gleiche Jobnummer angezeigt wird. Stimmen die beiden Nummern nicht überein, so soll der Benutzer seine PIN nicht eingeben und stattdessen weitergehende Schritte zur Klärung des aufgetretenen Fehlverhaltens einleiten.
    <=

    TIP1-A_4642

    Zur hinreichend eindeutigen Kennzeichnung des Vorganges MUSS eine Jobnummer von einem Zufallswert abgeleitet sein, wobei die Vorgaben an einen solchen Zufallswert beachtet werden MÜSSEN [gemSpec_Krypt#2.2].

    <=

    TIP1-A_4643

    Zur Wahrung der Benutzerfreundlichkeit MUSS eine Reduzierung der Jobnummer auf eine Länge von sechs Zeichen erfolgen. Diese sechs Zeichen MÜSSEN in zwei Zeichengruppen mit je drei Zeichen, getrennt durch einen Bindestrich (0x2D), dargestellt werden. Die erste Zeichengruppe MUSS ausschließlich die Zeichen "A-Z" beinhalten, die zweite Zeichengruppe MUSS aus Ziffern "0-9" bestehen. Die Länge der resultierenden, reduzierten Jobnummer ist sieben und wird durch den Umfang der darstellbaren Zeichen auf dem Display des eHealth-Kartenterminals beschränkt.
    <=

    TIP1-A_4644

    Der Konnektor MUSS die Eindeutigkeit einer Jobnummer sicherstellen:

    <=

    TIP1-A_4645

    Die einzelnen Zeichen der Jobnummer MÜSSEN für die Anzeige am Kartenterminal gemäß dem Zeichensatz ISO 646DE/DIN66003, bzw. ISO 646 US codiert werden. Aus diesem Zeichensatz dürfen nur die Zeichen „A-Z“ (0x41 bis 0x5A) und die Ziffern „0-9“ (0x30 bis 0x39) für die Anzeige der Jobnummer verwendet werden.
    <=

    Beispiele für eine Jobnummer sind ABC-475 und HZF-696.

    Die Einbettung der Jobnummer in den Nachrichtentext für den Bildschirm des Kartenlesers wird in TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal beschrieben.

    4.1.8.1.5 Komfortsignatur

    Für die QES unterstützt der Konnektor die Komfortsignaturfunktion. In diesem Modus können für ein- und denselben HBA mehrere vom Clientsystem initiierte Signaturaufträge (Einzel- oder Stapelsignatur) abgearbeitet werden, ohne dass der Inhaber des HBA für jeden einzelnen dieser Signaturaufträge die PIN.QES am Kartenterminal eingegeben muss.

    Im Auslieferungszustand ist die Komfortsignaturfunktion ausgeschaltet (SAK_COMFORT_SIGNATURE = Disabled), d. h. mit dem Konnektor können zunächst keine Komfortsignaturen durchgeführt werden. Die Komfortsignaturfunktion kann vom Administrator eingeschaltet werden. Dies ist nur möglich, wenn an der Clientsystemschnittstelle des Konnektors verpflichtend TLS mit Clientauthentisierung (Konfigurationsvariante SOAP1 und SOAP2 in TAB_KON_852) konfiguriert ist. Das Einschalten der Komfortsignaturfunktion im Konnektor hat zur Folge, dass alle Operationen an der Clientsystemschnittstelle nur über TLS mit Clientauthentisierung angesprochen werden können (außer ggf. Dienstverzeichnisdienst).

    Bei eingeschalteter Komfortsignaturfunktion können potentiell alle HBAs in der Umgebung, in der der Konnektor eingesetzt ist, Komfortsignaturen durchführen. Die eigentliche Aktivierung der Komfortsignatur muss separat für jede einzelne HBA-CardSession erfolgen.

    Durch Aufruf der Operation ActivateComfortSignature des Konnektors durch das Primärsystem wird die Nutzung der Komfortsignatur für eine HBA-CardSession (Komfortsignaturmodus) aktiviert. Dazu muss der HBA-Inhaber die PIN.QES eingeben.

    Der Konnektor merkt sich für die Cardsession des HBA, dass die Komfortsignatur aktiviert wurde. Bei den folgenden Aufrufen von SignDocumentwerden dann Komfortsignaturen ausgeführt, solange bis eines der folgenden Abbruchkriterien eintritt:

    ·       Die vom HBA (entsprechend Personalisierung) oder die vom Konnektor (entsprechend Konfiguration SAK_COMFORT_SIGNATURE_MAX) durchgesetzte maximale Anzahl von Signaturen wurde erreicht.

    ·       Das konfigurierte Zeitintervall für die Komfortsignatur (entsprechend Konfiguration SAK_COMFORT_SIGNATURE_TIMER) ist für die Cardsession abgelaufen.

    ·       Der Komfortsignaturmodus wurde für die betroffene Cardsession deaktiviert.

    ·       Der HBA wurde gezogen.

    ·       Der Sicherheitszustand des HBA wurde zurückgesetzt.

    ·       Die Komfortsignaturfunktion wurde für den Konnektor durch den Administrator deaktiviert.

    A_19945

    Der Signaturdienst MUSS bei der Komfortsignatur die Signaturvarianten für die QES gemäß TAB_KON_778 unterstützen. <=

    A_18597

    Bei der Komfortsignatur DARF der Konnektor den Sicherheitszustand der PIN.QES NICHT selbsttätig zurücksetzen, außer wenn dies explizit spezifikatorisch gefordert wird. <=

    A_18597 kann z. B. umgesetzt werden, indem

    ·       ein dedizierter logischer Kanal des HBA für die Komfortsignatur verwendet wird und

    ·       im dedizierten logischen Kanal des HBA die Selektion von DF.QES solange beibehalten wird, bis ein Verlassen von DF.QES durch die Spezifikation explizit gefordert wird.

    A_18686-01

    Der Konnektor MUSS für jede HBA-Kartensitzung mit eingeschalteter Komfortsignatur einen Komfortsignatur-Timer gemäß konfiguriertem Zeitintervall SAK_COMFORT_SIGNATURE_TIMER einrichten.
    Der Konnektor DARF nach Erreichen des Maximalwerts des Timers NICHT weitere Signaturaufträge annehmen.
    Der Konnektor MUSS den Sicherheitszustand des HBA nach Erreichen des Maximalwertes des Timers zurücksetzen, nachdem Signaturaufträge, die bis zu diesem Zeitpunkt bereits zur Bearbeitung angenommen wurden, vollständig abgearbeitet wurden.
    <=

    A_19100-01

    Der Konnektor MUSS für jede HBA-Kartensitzung mit eingeschalteter Komfortsignatur die an die Karte gesendeten Signaturaufträge zählen und nach Erreichen von SAK_COMFORT_SIGNATURE_MAX den Sicherheitszustand des HBA zurücksetzen.
    <=

    A_19258

    Bei der Komfortsignatur MUSS der Signaturdienst die zu signierenden Daten (DTBS) über Secure Messaging vom Konnektor zum HBA übertragen. Dieser Secure Messaging-Kanal MUSS über die gSMC-K zum HBA mittels C.SAK.AUTD_CVC aufgebaut werden. <=

    A_20073-01

    Der Konnektor MUSS die beim Aktivieren des Komfortsignaturmodus vom PS übermittelte UserId für die Kartensitzung des HBA, für den der Modus aktiviert wird, auf die ausreichende Länge von 128 Bit im Format einer UUID nach RFC4122 prüfen und die Aktivierung mit Fehler 4272 ablehnen, wenn die UserId nicht ausreichend lang ist. <=

    A_20074

    Der Konnektor MUSS die Eindeutigkeit der UserId sicherstellen. Wird die Operation ActivateComfortSignature mit einer UserId im Aufrufkontext aufgerufen, die innerhalb der vorangegangenen 1.000 Vorgänge bereits verwendet wurde, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4270 abbrechen. Die Zählung der Aufrufe erfolgt dabei unabhängig vom Aufrufkontext. <=

    A_19101

    Das Handbuch des Konnektors MUSS einen Hinweis enthalten, dass die Authentifizierung des HBA-Inhabers für die Komfortsignatur vom Clientsystem vorgenommen wird und dass die Authentifizierung des Nutzers am Clientsystem einen unverzichtbaren Beitrag zur Sicherheit der Lösung leistet. <=

    A_22344

    Der Konnektor MUSS mindestens zwei parallele Komfortsignatursessions für ein- und denselben HBA unterstützen.
    <=

    Es kann davon ausgegangen werden, dass in den Einsatzumgebungen des Konnektors fachlicher Bedarf an mehr als zwei parallelen Komfortsignatursessions besteht. Daher wird empfohlen, mehr als zwei Sessions zu unterstützen.

    Um pro Session die maximal erlaubte Anzahl von Signaturen (SAK_COMFORT_SIGNATURE_MAX) ausschöpfen zu können, sollen für parallele Komfortsignatursessions nach Möglichkeit mehrere logische Kanäle des HBA verwendet werden.

    Der Konnektor soll sich robust verhalten, wenn zu einem HBA Signaturaufträge von unterschiedlichen Clientsystemen aus eintreffen, während vorherige Signaturaufträge noch nicht vollständig abgearbeitet sind. Nach Möglichkeit sollen gleichzeitig eintreffende Signaturaufträge angenommen und abgearbeitet werden.

    A_22352

    Der Konnektor SOLL die Komfortsignatur-Timer paralleler Komfortsignatursessions für ein- und denselben HBA so umsetzen, dass diese unabhängig voneinander wirken. <=

    A_22459

    Der Konnektor SOLL die Komfortsignatur-Zähler paralleler Komfortsignatursessions für ein- und denselben HBA so umsetzen, dass diese unter Berücksichtigung der Limitierungen der Karte unabhängig voneinander wirken. <=

    4.1.8.2 Durch Ereignisse ausgelöste Reaktionen

    keine

    4.1.8.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Abbildung PIC_KON_103 Use Case Diagramm Signaturdienst (nonQES) beschreibt die Aufrufbeziehungen der nonQES-TUCs des Signaturdienstes. Die TUCs des Signaturdienstes sind weiß dargestellt. Genutzte TUCs anderer Basisdienste sind grau hinterlegt.

    Abbildung 15: PIC_KON_103 Use Case Diagramm Signaturdienst (nonQES)

    Abbildung PIC_KON_104 Use Case Diagramm Signaturdienst (QES) beschreibt die Aufrufbeziehungen der QES-TUCs des Signaturdienstes.



    Abbildung 16: PIC_KON_104 Use Case Diagramm Signaturdienst (QES)

    Abbildung PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur) beschreibt die Aufrufbeziehungen der TUCs des Signaturdienstes für die Komfortsignatur.

    Abbildung 17: PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur)

    4.1.8.3.1 TUC_KON_155 „Dokumente zur Signatur vorbereiten”

    TIP1-A_4646-04

    Der Konnektor MUSS den technischen Use Case TUC_KON_155 „Dokumente zur Signatur vorbereiten” umsetzen.

    Tabelle 193: TAB_KON_748 - TUC_KON_155 „Dokumente zur Signatur vorbereiten“

    Element
    Beschreibung
    Name
    TUC_KON_155 ”Dokumente zur Signatur vorbereiten”
    Beschreibung
    Die zu signierenden Dokumente werden entsprechend den Erfordernissen
    der Signaturverfahren für die QES oder nonQES vorbereitet.

    Anwendungsumfeld
    Erstellung von qualifizierten elektronischen Signaturen (QES) und
    nicht-qualifizierten elektronischen Signaturen (nonQES)

    Auslöser
    Aufruf durch TUC_KON_150 „Dokumente QES signieren“ oder
    TUC_KON_160 „Dokumente nonQES signieren“

    Vorbedingungen
    keine
    Eingangsdaten
     -  signatureMode
        (Signaturart: QES | nonQES)

     -  documentsToBeSigned
        (Zu signierendes Dokument bzw. zu signierende Dokumente) und pro
        Dokument:

     -  documentFormat
        (Formatangabe für das zu signierende Dokument)

     -  optionalInputs
        (weitere optionale Eingabeparameter zur Steuerung der Details bei der
       zu erstellenden Signatur (siehe Operation SignDocument, Parameter
       dss:OptionalInputs), darin u.a.

       -signatureType
           (URI für den Signaturtyp XML-, CMS-, S/MIME-o PDF-Signatur)

     -  certificate
        (Signaturzertifikat)

     -  ocspResponses – optional
        (OCSP-Response des EE-Zertifikats, das bei der Signaturerstellung in
       die Signatur eingebettet wird.)


    Komponenten
    Konnektor
    Ausgangsdaten
    • preProcessedDocuments
      (Aufbereitetes zu signierendes Dokument bzw. aufbereitete zu signierende Dokumente)

    Standardablauf
    signatureType  = XMLDSig (XAdES)
    Entsprechend den Regeln für die QES und die nonQES werden zunächst
    weitere Signatureigenschaften zum jeweiligen Dokument in Form von
    QualifyingProperties (siehe [XAdES]) hinzugefügt.
    Die Systemzeit des Anwendungskonnektors muss in das XML-Element
    SigningTime (siehe [XAdES]) eingetragen werden. Die Signatur wird
    anschließend entsprechend [XMLDSig] vorbereitet. D. h., es wird je
    Dokument nach Erzeugung der Reference Elemente das SignedInfo
    Element aufgebaut. Dessen Inhalt ergibt dann nach erfolgter
    XML-Kanonisierung und Hashing die DTBS (Data To Be Signed), die
    später zur Karte gesendet werden.

    certificate wird im Element ds:KeyInfo/ds:X509Data gespeichert.

    Im Fall signatureMode = QES können neben den reinen Nutzdaten auch
    alle weiteren Elemente in die Signatur einbezogen werden, die für die
    Rekonstruktion der ursprünglich dargestellten Daten in der sicheren
    Anzeige erforderlich sind. Für XML-Dokumente sind das, falls vorhanden,
    das/die XML-Schema(ta). Für diese werden Referenzen (Hash + URI) in
    die Signatur eingebettet.

    Die URI ist im Fall übergebener XML-Schemata der übergebene
    signatureType - Parameter. Die URI ist im Fall der im Konnektor im
    Rahmen einer Signaturrichtlinie hinterlegten XML-Schemata/XSL-
    Stylesheets die URI der Signaturrichtlinie, ergänzt um den Dateinamen
    mit Pfad, wie in der Signaturrichtlinie festgelegt.


    (Beispiel: URI für Schemadatei NFD_Document.xsd der Signaturrichtlinie SR_DF_NFDM_NOTFALLDATEN lautet: urn:gematik:fa:sak:nfdm:r1:v1:NFD_Document.xsd)
    Das Einbetten der Referenzen erfolgt über das XML-Element
    ds:object/ds:manifest (XMLDSig) mit eingebetteten XML-Elementen
    ds:Reference, die eine URI (RefURI) als Identifier für die jeweilige Datei
    und einen Hash über die jeweilige Resource enthalten.
    Der ShortTextClientsystem muss in die Signatur in das
    DataObjectFormat/Description-Element gemäß [XAdES]
    (Abschnitt 7.2.5) eingebettet werden.

    Falls durch den Aufrufparameter SIG:IncludeRevocationInfo
    angefordert, wird die für die Offline-Prüfung notwendige OCSP-Antwort
    im Sinne vom ES-X-L vom Konnektor in die Signatur eingebettet:

    Die base-64 kodierte OCSP-Response wird im Feld
    QualifyingProperties/UnsignedProperties
    /UnsignedSignatureProperties/RevocationValues
    /OCSPValues/EncapsulatedOCSPValue
    (selbst DER-kodiert)
    gespeichert.

    signatureType  = CMS (CAdES)
    Etwaig einzubettende XML-Schemata werden zunächst wie für XAdES
    definiert in ein ds:manifest-Element eingebettet. Die so erzeugte
    Zeichenkette wird als genau ein ASN.1 Character String vom Typ
    UTF8String verpackt. Dieser wird als contentDescription in einen
    Content-Hints Attributwert vom Typ ContentHints verpackt, wobei der
    contentType=id-data gemäß [CAdES].

    Der ShortTextClientsystem muss in die Signatur in das  content-
    hints.ContentDescription
    -Attribut gemäß [CAdES] (Abschnitt
    5.10.3) eingebettet werden.

    Ist die Einbettung von OCSP-Responses gefordert, wird die für die
    Offline-Prüfung notwendige OCSP-Antwort des EE-Zertifikats im Attribut
    SingedData.crls.other abgelegt.

    signatureType  = PDF/A (PAdES)
    Der ShortTextClientsystem muss bei einer PDF-Signatur in das
    Reason-Feld eingebettet werden.

    OCSP-Responses werden bei PAdES nicht eingebettet.

    Es sind die Vorgaben zum Signaturprofil gemäß Tabelle TAB_KON_779-01
    „Profilierung der Signaturformate“ zu erfüllen.

    Die aufbereiteten zu signierenden Dokumente werden an den Aufrufer
    zurückgegeben.

    Varianten/
    Alternativen

    keine
    Fehlerfälle
    Das Verhalten des TUCs bei einem Fehlerfall ist in TAB_KON_586
    Fehlercodes TUC_KON_155 „Dokumente zur Signatur vorbereiten“
    „PDF/A (PAdES)“

    Es ist nicht genügend Speicherplatz im PDF-Dokument verfügbar: 4205
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 194: TAB_KON_586 Fehlercodes TUC_KON_155 „Dokumente zur Signatur vorbereiten“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4205
    Technical
    Error
    Es ist nicht genügend Speicherplatz im PDF-Dokument verfügbar.

    <=

    4.1.8.3.2 TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“

    TIP1-A_4647-02

    Der Konnektor MUSS den technischen Use Case „Signaturvoraussetzungen für nonQES prüfen” umsetzen.

    Tabelle 195: TAB_KON_749 – TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“

    Element
    Beschreibung
    Name
    TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
    Beschreibung
    Es werden die Voraussetzungen an die zu signierenden Dokumente und das Signaturzertifikat geprüft. Es werden die nonQES_DocFormate unterstützt.
    Auslöser
    TUC_KON_160 „Dokumente nonQES signieren“
    Vorbedingungen
    keine
    Eingangsdaten
    • Zu signierende Dokumente
    • optionale Eingabeparameter zur Steuerung der Details der Signaturerstellung
    • cardSession Signaturkarte
    • zu verwendende Identität (Zertifikatsreferenz)
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte
    Ausgangsdaten
    • Prüfergebnis
    • Signaturzertifikat
    Standardablauf
    1. Abhängig von seinem Typ werden für jedes Dokument die typabhängigen Validierungsschritte (ohne Prüfung auf sichere Anzeigbarkeit) durchgeführt. Dies geschieht durch Aufruf von TUC_KON_080 „Dokument validieren“. Wird der Aufruf von TUC_KON_080 mit einem Fehler beendet, wird die Prüfung im laufenden TUC mit diesem Fehler abgebrochen.
    2. Durch Aufruf von TUC_KON_216 „Lese Zertifikat“ wird das Signaturzertifikat von der Signaturkarte gelesen.
    3. Das Signaturzertifikat wird durch Aufruf von
      TUC_KON_037 „Zertifikat prüfen“{

         certificate = Zertifikatsreferenz;
         qualifiedCheck = not_required;
         offlineAllowNoCheck = true;
         validationMode = OCSP}
      geprüft.
    Varianten/Alterna-tiven
    Keine
    Fehlerfälle
    Keine
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 196: TAB_KON_587 Fehlercodes TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

    <=

    4.1.8.3.3 TUC_KON_166 „nonQES Signaturen erstellen“

    TIP1-A_4648

    Der Konnektor MUSS den technischen Use Case TUC_KON_166 „nonQES Signaturen erstellen” umsetzen.

    Tabelle 197: TAB_KON_750 – TUC_KON_166 „nonQES Signaturen erstellen“

    Element
    Beschreibung
    Name
    TUC_KON_166 „nonQES Signaturen erstellen“
    Beschreibung
    Die Data To Be Signed (DTBS) werden erzeugt, an die Signaturkarte gesendet und dort signiert.
    Auslöser
    TUC_KON_160 „Dokumente nonQES signieren“
    Vorbedingungen
    keine
    Eingangsdaten
    • Liste der zu signierenden Dokumente
    • cardSession Signaturkarte
    • zu verwendende Identität (Zertifikatsreferenz)
    • crypt [SIG_CRYPT_nonQES]: optional;
      default und Wertebereich: SIG_CRYPT_DEFAULT siehe TAB_KON_863
      (Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte
    Ausgangsdaten
    • Signierte Dokumente
    Standardablauf
    Die folgenden Schritte werden für jedes Dokument der Liste durchgeführt.
    1.       Das zu signierende Dokument wird, soweit noch nicht erfolgt, für die XML-Signatur vorbereitet. Ein Ergebnis dieser Vorbereitung sind die Data To Be Signed (DTBS): der Hash-Wert (Digest des SignedInfo-Elementes), der zur Signatur an die Karte gesendet werden soll.
      Für XML-Signaturen müssen die Vorgaben aus [gemSpec_Krypt#3.1.1] beachtet werden.

    2.       Für das zu signierende Dokument werden die DTBS zur Signatur an die Signaturkarte übermittelt (Aufruf von TUC_KON_218 „Signiere“). Dabei werden der Schlüssel und der Algorithmusidentifier über die Tabelle TAB_KON_900 bestimmt.
    3.       Die erstellte Signatur wird mathematisch geprüft.
    4.       Der ermittelte Signaturwert wird in die zuvor vorbereitete XML-Signatur eingefügt.
    5.       Der Konnektor löst TUC_KON_256 {"SIG/SIGNDOC/NEXT_SUCCESSFUL"; Op; Info; „$Jobnummer"; noLog; $doInformClients } aus.
    Varianten/Alternativen
    keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
    (3) Fehlgeschlagene mathematische Prüfung der Signatur: 4120
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 198: TAB_KON_120 Fehlercodes TUC_KON_166 „nonQES Signaturen erstellen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4120
    Security
    Error
    Kartenfehler

    <=

    4.1.8.3.4 TUC_KON_152 "Signaturvoraussetzungen für QES prüfen"

    TIP1-A_4649

    Der Konnektor MUSS den technischen Use Case TUC_KON_152 „Signaturvoraussetzungen für QES prüfen” umsetzen.

    Tabelle 199: TAB_KON_751 – TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“

    Element
    Beschreibung
    Name
    TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
    Beschreibung
    Es werden die Voraussetzungen an die zu signierenden Dokumente und das Signaturzertifikat geprüft. Es werden die QES_DocFormate unterstützt.
    Auslöser
    TUC_KON_150 „Dokumente QES signieren“
    Vorbedingungen
    keine
    Eingangsdaten
    • Zu signierende Dokumente
    • optionale Eingabeparameter zur Steuerung der Details der Signaturerstellung
    • cardSession Signaturkarte
    • zu verwendende Identität (Zertifikatsreferenz)
    • includeRevocationInfo [Boolean] - optional; Default: true
      (Dieser Parameter steuert die Einbettung von OCSP-Responses in die Signatur.
      true: Die Sperrinformationen werden in ocspResponses zurückgegeben.)

    Komponenten
    Konnektor, Kartenterminal, Signaturkarte
    Ausgangsdaten
    • Prüfergebnis
    • Signaturzertifikat
    • ocspResponses - optional/nur wenn includeRevocationInfo = true
      (OCSP-Response des EE-Zertifikats, die beim Aufruf von TUC_KON_037 „Zertifikat prüfen“ zurückgegeben wird)

    Standardablauf
    1.       Abhängig von seinem Typ werden für jedes Dokument die typabhängigen Dokumentvalidierungsschritte durchgeführt (Aufruf TUC_KON_080 „Dokument validieren“). Wird der Aufruf von TUC_KON_080 mit einem Fehler beendet, wird die Prüfung im laufenden TUC mit diesem Fehler abgebrochen.
    2.       Durch Aufruf von TUC_KON_216 „Lese Zertifikat“ wird das Signaturzertifikat von der Signaturkarte gelesen.
    3.       Das Signaturzertifikat wird durch Aufruf von TUC_KON_037 „Zertifikat prüfen“{
         certificate = Zertifikatsreferenz;
         qualifiedCheck = required;
         offlineAllowNoCheck = true;
         validationMode = OCSP;
         getOCSPResponses = includeRevocationInfo}
      geprüft.
    Varianten/Alternativen
    keine
    Fehlerfälle
    (->3) Für MGM_LU_ONLINE=Enabled gilt:
    Liefert die Zertifikatsprüfung (OCSP-Abfrage) die Warnung CERT_REVOKED oder CERT_UNKNOWN gemäß [gemSpec_PKI#Tab_PKI_274], dann wird der TUC mit Fehler 4123 abgebrochen.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 200: TAB_KON_588 Fehlercodes TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

    <=

    4.1.8.3.5 TUC_KON_154 "QES Signaturen erstellen"

    Der TUC_KON_154 stellt den Standardsignaturfall in der TI, die Stapelsignatur dar (auch für Stapel der Größe 1). Da die Stapelsignatur auf der Zielkarte passende CVC voraussetzt, die auf den HBA-Vorläuferkarten nicht vorhanden sind, kann dieser TUC nur den HBA unterstützen. Für HBA-Vorläuferkarten kann TUC_KON_168 verwendet werden.

    TIP1-A_4651-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_154 „QES Signaturen erstellen” umsetzen.

    Tabelle 201: TAB_KON_752 – TUC_KON_154 „QES Signaturen erstellen"

    Element
    Beschreibung
    Name
    TUC_KON_154 „QES Signaturen erstellen“
    Beschreibung

    Die Data To Be Signed (DTBS) werden erzeugt, an die Signaturkarte gesendet und dort signiert.
    Auslöser
    TUC_KON_150 „Dokumente QES signieren“
    Vorbedingungen

    Die Ressourcen Signaturkarte und Kartenterminal sind für den Vorgang reserviert.
    DF.QES ist selektiert.
    PIN.QES ist initial verifiziert
    Eingangsdaten

    • Zu signierendes Dokument bzw. zu signierende Dokumente
    • cardSession (nur HBA erlaubt)
    • zu verwendende Identität (Zertifikatsreferenz)
    • crypt [SIG_CRYPT_QES] - optional;
      default und Wertebereich: siehe TAB_KON_862-01
      (Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)
    • WorkplaceId
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte (HBA)
    Ausgangsdaten
    • Signierte Dokumente
    Standardablauf

    Basierend auf SAK.AUTD_CVC und HPC.AUTD_SUK_CVC und den zugehörigen privaten Schlüsseln wird ein sicherer Kanal zwischen der gSMC-K des Konnektors und dem HBA aufgebaut mittels Aufruf TUC_KON_005 „Card-to-Card authentisieren“ {  
         sourceCardSession = gSMC-K;
         targetCardSession = CardSession;
         authMode = „gegenseitig+TC“}

    Die folgenden Schritte werden für jedes Dokument des Stapels durchgeführt.
    1. Das zu signierende Dokument wird, soweit noch nicht erfolgt, für die Signatur gemäß des entsprechenden Formats vorbereitet. Ein Ergebnis dieser Vorbereitung sind die Data To Be Signed (DTBS): der Hash-Wert (Digest des SignedInfo-Elementes), der zur Signatur an die Karte gesendet werden soll.
    2. Für das zu signierende Dokument werden die DTBS zur Signatur im sicheren Kanal an den HBA übermittelt (Aufruf TUC_KON_218 „Signiere“). Dabei werden der Schlüssel und der Algorithmusidentifier über die Tabelle TAB_KON_900 bestimmt.
    3. Falls Schritt 3 fehlgeschlagen ist, weil der PIN.QES-Nutzungszähler abgelaufen ist (erkennbar z. B. daran, dass die Karte einen Autorisierungsfehler zurückmeldet), wird die PIN.QES verifiziert (Aufruf TUC_KON_012 „PIN verifizieren“, nachdem der im Konnektor verwaltetete Sicherheitszustand (CARDSESSION.AUTHSTATE) aktualisiert wurde). Am Display des Kartenterminals wird dabei die Jobnummer für den Signaturvorgang angezeigt. Aus der WorkplaceId geht hervor, ob es sich um eine Remote-PIN-Eingabe handelt. Nach der PIN-Verifikation wird erneut die zuvor fehlgeschlagene Signatur in Schritt 3 ausgeführt.
    4. Die erstellte Signatur wird mathematisch geprüft.
    5. Der ermittelte Signaturwert wird in den zuvor vorbereiteten Signaturprototypen eingefügt.
    6. Der Konnektor löst TUC_KON_256 {"SIG/SIGNDOC/NEXT_SUCCESSFUL"; Op; Info; „$Jobnummer"; noLog; $doInformClients } aus.
    Varianten/
    Alternativen

    Alternativ zum Standardablauf kann zu Beginn die maximal erlaubte Stapelgröße SSEC durch Auslesen von EF.SSEC ermittelt werden. Der zu signierende Dokumentenstapel wird in Teilstapel von maximaler Größe SSEC zerlegt. Für jeden Teilstapel wird die PIN.QES verifiziert. Die Dokumente des Teilstapels werden wie im Standardablauf beschrieben signiert.
    Der Nutzer kann den Vorgang der PIN-Eingabe abbrechen.
    Fehlerfälle

    (->2) Fehler im Signaturvorgang führen zum Abbruch des gesamten Signaturvorgangs, Fehlercode 4123
    (->3) Fehler bei der PIN-Eingabe führen zum Abbruch des Signaturvorgangs
    (->4) Fehler in mathematischer Prüfung der Signatur führen zum Abbruch des Signaturvorgangs, Fehlercode 4120
    Das Verhalten des TUCs bei einem Fehlerfall, einem Timeout der PIN-Eingabe oder beim Abbruch durch den Benutzer ist in Tabelle TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur beschrieben.
    Sicherheitsanforderungen

    Zum Aufbau des sicheren Kanals bzw. zur Aushandlung des symmetrischen Schlüssels DARF DF.QES NICHT verlassen werden. Benötigte CVCs des HBA MÜSSEN also bereits vor dem Signaturvorgang eingelesen und gecacht werden. Dies KANN bereits beim Stecken des HBA geschehen.
    Die in [gemSpec_Krypt#3.1.2] angegebenen Festlegungen der zu unterstützenden Algorithmen MÜSSEN berücksichtigt werden.
    Nichtfunktionale Anforderungen
    keine

    Zugehörige Diagramme

    Abbildung PIC_KON_113 Aktivitätsdiagramm zu „QES Signaturen erstellen“
    Das Diagramm dient nur der Veranschaulichung und ist nicht vollständig. Beispielsweise enthält es nicht die Steuerung durch den Parameter crypt.



    Abbildung 18: PIC_KON_113 Aktivitätsdiagramm zu „QES Signaturen erstellen“

    Tabelle 202: TAB_KON_126 Fehlercodes TUC_KON_154 „QES Signaturen erstellen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4120
    Security
    Error
    Kartenfehler
    4123
    Security
    Error
    Fehler bei Signaturerstellung
    <=

    4.1.8.3.6 TUC_KON_168 „Einzelsignatur QES erstellen“

    TIP1-A_4652-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_168 „Einzelsignatur QES erstellen“ umsetzen.


    Tabelle 203: TAB_KON_293 - TUC_KON_168 „Einzelsignatur QES erstellen“

    Element
    Beschreibung
    Name
    TUC_KON_168 ”Einzelsignatur QES erstellen”
    Beschreibung
    Es wird ein Dokument technisch mit einer Signatur versehen.
    Im Gegensatz zum TUC_KON_154 „QES Signaturen erstellen“ wird hier nur eine einzelne Signatur ohne vorhergehendes C2C erstellt. Die Übertragung der DTBS erfolgt ohne Secure Messaging.
    Auslöser
    TUC_KON_150 Dokumente QES signieren
    Vorbedingungen
    Die Ressourcen Signaturkarte und Kartenterminal sind für den Vorgang reserviert.
    DF.QES ist selektiert.
    Eingangsdaten
    • zu signierendes Dokument
    • CardSession (HBAx)
    • zu verwendende Identität (Zertifikatsreferenz)
    • crypt: [SIG_CRYPT_QES] - optional;
      default und Wertebereich: siehe TAB_KON_862-01
      Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.

    • WorkplaceId
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte (HBAx)
    Ausgangsdaten
    • Signiertes Dokument
    Standardablauf


    1. Das zu signierende Dokument wird, soweit noch nicht erfolgt, für die Signatur vorbereitet. Ein Ergebnis dieser Vorbereitung sind die DTBS: der Hash-Wert (Digest des SignedInfo-Elementes), der zur Signatur an die Karte gesendet werden soll.
    2. Für das zu signierende Dokument werden die DTBS zur Signatur an den HBAx übermittelt (Aufruf TUC_KON_218 „Signiere“). Dabei werden der Schlüssel und der Algorithmusidentifier über die Tabelle TAB_KON_900 bestimmt.
      Jeder Fehler führt zum Abbruch des Signaturvorgangs

    3. Die erstellte Signatur wird mathematisch geprüft. Der ermittelte Signaturwert wird in den zuvor gemäß des entsprechenden Signaturformates vorbereiteten Signaturprototypen eingefügt.
    Varianten/
    Alternativen

    keine
    Fehlerfälle
    Das Verhalten des TUCs bei einem Fehlerfall, einem Timeout der PIN-Eingabe oder beim Abbruch durch den Benutzer ist in Tabelle TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur beschrieben.
    (3) Fehler in mathematischer Prüfung der Signatur: Abbruch mit 4120
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 204: TAB_KON_590 Fehlercodes TUC_KON_168 „Einzelsignatur QES erstellen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten.
    4120
    Security
    Error
    Kartenfehler

    <=

    4.1.8.3.7 TUC_KON_158 "Komfortsignaturen erstellen"

    Der TUC_KON_158 führt die Komfortsignatur für ein Dokument oder mehrere Dokumente eines Stapels aus. Da die Komfortsignatur auf der Zielkarte passende CVC voraussetzt, die auf den HBA-Vorläuferkarten nicht vorhanden sind, unterstützt dieser TUC nur den HBA.

    A_19102-04

    Der Konnektor MUSS den technischen Use Case TUC_KON_158 „Komfortsignaturen erstellen” umsetzen.

    Tabelle 205: TAB_KON_870 – TUC_KON_158 „Komfortsignaturen erstellen"

    Element
    Beschreibung
    Name
    TUC_KON_158 „Komfortsignaturen erstellen“
    Beschreibung


    Die Data To Be Signed (DTBS) werden erzeugt, an die Signaturkarte gesendet und dort signiert.
    Die Übertragung der DTBS erfolgt mit Secure Messaging.
    Die Abarbeitung der Signatur erfolgt im SE#2.
    Auslöser
    TUC_KON_170 „Dokumente mit Komfort signieren“
    Vorbedingungen


    Die Ressource Signaturkarte ist für den Vorgang reserviert.
    DF.QES ist selektiert.
    PIN.QES ist initial verifiziert
    Eingangsdaten


    ·         Zu signierendes Dokument bzw. zu signierende Dokumente
    ·         cardSession (nur HBA erlaubt)
    ·         zu verwendende Identität (Zertifikatsreferenz)
    ·         crypt [SIG_CRYPT_QES] - optional ;
    default und  Wertebereich: siehe TAB_KON_862-01
    (Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)
    ·         WorkplaceId
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte (HBA)
    Ausgangsdaten
    ·         Signierte Dokumente
    Standardablauf


    1.    Wenn noch nicht erfolgt, wird basierend auf SAK.AUTD_CVC und HPC.AUTD_SUK_CVC und den zugehörigen privaten Schlüsseln ein sicherer Kanal zwischen der gSMC-K des Konnektors und dem HBA aufgebaut mittels Aufruf TUC_KON_005 „Card-to-Card authentisieren“ {  
         sourceCardSession = gSMC-K;
         targetCardSession = CardSession;
         authMode = „gegenseitig+TC“}

    Die folgenden Schritte werden für jedes Dokument des Stapels durchgeführt.
    2.    Das zu signierende Dokument wird, soweit noch nicht erfolgt, für die Signatur gemäß des entsprechenden Formats vorbereitet. Ein Ergebnis dieser Vorbereitung sind die Data To Be Signed (DTBS): der Hash-Wert (Digest des SignedInfo-Elementes), der zur Signatur an die Karte gesendet werden soll.
    3.    Es wird geprüft, ob der Komfortsignatur-Zähler der cardSession den Wert SAK_COMFORT_SIGNATURE_MAX überschritten hat .
     
    4.    Für das zu signierende Dokument werden die DTBS zur Signatur im sicheren Kanal an den HBA übermittelt (Aufruf TUC_KON_218 „Signiere“). Dabei werden der Schlüssel und der Algorithmusidentifier über die Tabelle TAB_KON_900 bestimmt.
    5.    Der Komfortsignatur-Zähler der cardSession wird um 1 erhöht.
    6.    Die erstellte Signatur wird mathematisch geprüft.
    7.    Der ermittelte Signaturwert wird in den zuvor vorbereiteten Signaturprototypen eingefügt.
    8.    Der Konnektor löst TUC_KON_256 {"SIG/SIGNDOC/NEXT_SUCCESSFUL"; Op; Info; „$Jobnummer"; noLog; $doInformClients } aus.
    Varianten/
    Alternatien
    Keine



    Fehlerfälle


    In den Fehlerfällen, die zum Abbruch des Komfortsignaturmodus mit Fehlercode 4271 führen, wird vor dem Abbruch TUC_KON_172 für das cardHandle des HBA ausgeführt.
    (->3) Der Komfortsignatur-Zähler der cardSession hat den Maximalwert überschritten: Fehlercode 4271
    (->4) Der PIN.QES-Nutzungszähler der Karte ist abgelaufen (erkennbar z. B. daran, dass die Karte einen Autorisierungsfehler zurückmeldet): Fehlercode 4271
    (->4) Fehler im Signaturvorgang führen zum Abbruch des gesamten Signaturvorgangs: Fehlercode 4123
    (->6) Fehler in mathematischer Prüfung der Signatur führen zum Abbruch des Signaturvorgangs: Fehlercode 4120
    Das weitere Verhalten des TUCs bei einem Fehlerfall oder beim Abbruch durch den Benutzer ist in TAB_KON_192, Verhalten des Konnektors beim Abbruch einer Stapelsignatur, beschrieben.
    Sicherheitsanforderungen


    Zum Aufbau des sicheren Kanals bzw. zur Aushandlung des symmetrischen Schlüssels DARF DF.QES NICHT verlassen werden. Benötigte CVCs des HBA MÜSSEN also bereits vor dem Signaturvorgang eingelesen und gecached werden. Dies KANN bereits beim Stecken des HBA geschehen.
    Komfortsignaturen MÜSSEN im SE#2 abgearbeitet werden.
    Die in [gemSpec_Krypt] angegebenen Festlegungen der zu unterstützenden Algorithmen MÜSSEN berücksichtigt werden.



    Tabelle 206: TAB_KON_873 Fehlercodes TUC_KON_158 „Komfortsignaturen erstellen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4120
    Security
    Error
    Kartenfehler
    4123
    Security
    Error
    Fehler bei Signaturerstellung


    <=

    4.1.8.4 Interne TUCs, auch durch Fachmodule nutzbar

    A_20478

    Der Konnektor KANN für die nonQES-Signaturerstellung an der Schnittstelle zu Fachmodulen zusätzliche Dokumentformate unterstützen. <=

    Die in der obigen Anforderung benannten Signaturen von Dokumentenformaten umfassen beispielsweise die Signatur von Token nach SAML2 für das Fachmodul ePA entsprechend [gemSpec_FM_ePA#A_14927].

    4.1.8.4.1 TUC_KON_160 „Dokumente nonQES signieren”

    TIP1-A_4653

    Der Konnektor MUSS den technischen Use Case TUC_KON_160 „Dokumente nonQES signieren” umsetzen.

    Tabelle 207: TAB_KON_753 – TUC_KON_160 „Dokumente nonQES signieren“

    Element
    Beschreibung
    Name
    TUC_KON_160 „Dokumente nonQES signieren“
    Beschreibung
    Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer nicht-qualifizierten elektronischen Signatur (nonQES) versehen. Es werden die nonQES_DocFormate unterstützt.
    Auslöser
    Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul.
    Vorbedingungen
    Die Signaturkarte muss gesteckt sein.
    Eingangsdaten
    • cardSession
      (Kartensitzung; zulässig sind SM-B, oder bei Aufruf durch Fachmodul auch zusätzlich eGK)
    • signRequests
      (Liste von Signaturaufträgen.)
      Jeder Signaturauftrag (SignRequest) kapselt:
      •       documentsToBeSigned
        (Zu signierendes Dokument bzw. zu signierende Dokumente);
        darin u.a.
        documentFormat (Formatangabe für das zu signierende Dokument)
      •       optionalInputs
        (weitere optionale Eingabeparameter zur Steuerung der Details bei der zu erstellenden Signatur, siehe Operation SignDocument, Parameter dss:OptionalInputs); darin u.a. signatureType (URI für den Signaturtyp XML-, CMS-, S/MIME-,  PDF-Signatur)
      •       includeRevocationInfo: – optional; default: true
        (Dieser optionale Parameter steuert die Einbettung von OCSP-Antworten in die Signatur: nur wirksam bei der Prüfung von enthaltenen Parallelsignaturen, wenn eine Gegensignatur erstellt werden soll. Die OCSP-Antworten werden in die jeweils geprüfte Parallelsignatur eingebettet.)
    • workplaceId
      (Identifikator des Arbeitsplatzes)
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte bzw. HSM-B
    Ausgangsdaten
    • signedDocuments
    (Liste der signierten Dokumente)
    Standardablauf
    Der Konnektor KANN die Schritte 1 bis 4 in einer beliebigen Reihenfolge durchführen.
    1.       Der signatureType und die Signaturvariante werden für jedes Dokument der Liste entsprechend SignatureType und SignatureVariant festgelegt. Wenn signatureType oder SignatureVariant nicht übergeben wurden (als Element von optionalInputs), wird das dem dokumentformat entsprechende Default-Verfahren gewählt (siehe TAB_KON_583 – Default-Signaturverfahren).
    2.       Für alle Dokumente des Stapels wird die Zulässigkeit des Kartentyps geprüft. Das für die Signatur zu nutzende Zertifikat wird anhand des Kartentyps implizit ausgewählt.
    3.       Es werden die Voraussetzungen für die Signatur geprüft. Dies erfolgt durch Aufruf von TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“.
    4.       Zum Vorbereiten der Dokumente für die Signatur wird TUC_KON_155 „Dokumente zur Signatur vorbereiten“ mit ocspResponses aufgerufen.
    5.       Die Signaturen werden durch den Aufruf von TUC_KON_166 erstellt.
    6.       Die signierten Dokumente werden an den Aufrufer zurückgegeben.
    Varianten/
    Alternativen
    Im Fall signatureType=S/MIME-Signatur
    wird der Standardablauf des CMS Signaturverfahrens durch einen vorgelagerten S/MIME-Vorbereitungsschritt und einen nachgelagerten S/MIME-Nachbereitungsschritt ergänzt. Das S/MIME-Verfahren MUSS konform [S/MIME] und SOLL konform [COMMON_PKI], Part 3, erfolgen.
    Der S/MIME-Vorbereitungsschritt bereitet das übergebene MIME-Dokument gemäß [S/MIME], Kapitel 3.1, auf die nachfolgende CMS-Signatur durch eine Kanonisierung für Text [S/MIME], Kapitel 3.1.1, vor. Eine weitere Kanonisierung oder eine Anpassung des Transfer Encodings [S/MIME], Kapitel 3.1.2, erfolgt nicht.
    Im S/MIME-Nachbereitungsschritt wird das im Standardablauf erzeugte CMS-Objekt in eine MIME-Nachricht vom Typ „application/pkcs7-mime“ eingebettet.
    Sämtliche Header-Felder der Nachricht MÜSSEN in die Header-Felder der S/MIME-Nachricht übernommen werden.
    "MIME-Version: 1.0" MUSS definiert sein.
    Das Feld "Content-Type:" ist als "application/pkcs7-mime" zu definieren. Die weiteren Attribute dieses Feldes sind:
    • "smime-type=signed-data;"
    • "name=$dateiname", wobei $dateiname auf ".p7m" endet.
    Die Codierung des signierten Inhalts der Nachricht MUSS in "base64" erfolgen. Entsprechend ist das zugehörige Header-Feld zu füllen: "Content-Transfer-Encoding: base64".
    Das Feld "Content-Disposition" definiert den Inhalt der Nachricht als Dateianhang: "Content-Disposition: attachment; filename=$dateiname"
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
    (2) Ungültige Angabe des Signaturverfahrens: Fehlercode 4111
             Übergabe eines für die nonQES nicht unterstützten
            Dokumentformats: Fehlercode 4110
      (3) Kartentyp nicht zulässig für Signatur: Fehlercode 4126
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 208: TAB_KON_127 Fehlercodes TUC_KON_160 „Dokumente nonQES signieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4110
    Technical
    Error
    ungültiges Dokumentformat (%Format%)
    Der Parameter Format enthält das übergebene Dokumentformat.
    4111
    Technical
    Error
    ungültiger Signaturtyp oder Signaturvariante
    4126
    Security
    Error
    Kartentyp nicht zulässig für Signatur
    <=

    TIP1-A_4653-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_160 „Dokumente nonQES signieren” umsetzen.

    Tabelle 209: TAB_KON_753 – TUC_KON_160 „Dokumente nonQES signieren“

    Element
    Beschreibung
    Name
    TUC_KON_160 „Dokumente nonQES signieren“
    Beschreibung
    Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer nicht-qualifizierten elektronischen Signatur (nonQES) versehen. Es werden die nonQES_DocFormate unterstützt.
    Auslöser
    Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul.
    Vorbedingungen
    Die Signaturkarte muss gesteckt sein.
    Eingangsdaten
    • cardSession
      (Kartensitzung; zulässig sind SM-B, oder bei Aufruf durch Fachmodul auch zusätzlich eGK)
    • crypt [SIG_CRYPT_nonQES] - optional;
      default und Wertebereich: siehe TAB_KON_863
      Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.
    • signRequests
      (Liste von Signaturaufträgen. Jeder Signaturauftrag (SignRequest) kapselt:
      •       documentsToBeSigned
        (Zu signierendes Dokument bzw. zu signierende Dokumente);
        darin u.a.
        documentFormat (Formatangabe für das zu signierende Dokument)
      •       optionalInputs
        (weitere optionale Eingabeparameter zur Steuerung der Details bei der zu erstellenden Signatur, siehe Operation SignDocument, Parameter dss:OptionalInputs); darin u.a. signatureType (URI für den Signaturtyp XML-, CMS-, S/MIME-,  PDF-Signatur)
      •       includeRevocationInfo: – optional; default: true
        (Dieser optionale Parameter steuert die Einbettung von OCSP-Antworten in die Signatur: nur wirksam bei der Prüfung von enthaltenen Parallelsignaturen, wenn eine Gegensignatur erstellt werden soll. Die OCSP-Antworten werden in die jeweils geprüfte Parallelsignatur eingebettet.)
    • workplaceId
      (Identifikator des Arbeitsplatzes)
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte bzw. HSM-B
    Ausgangsdaten
    • signedDocuments
    (Liste der signierten Dokumente)
    Standardablauf
    Der Konnektor KANN die Schritte 1 bis 4 in einer beliebigen Reihenfolge durchführen.
    1.       Der signatureType und die Signaturvariante werden für jedes Dokument der Liste entsprechend SignatureType und SignatureVariant festgelegt. Wenn signatureType oder SignatureVariant nicht übergeben wurden (als Element von optionalInputs), wird das dem dokumentformat entsprechende Default-Verfahren gewählt (siehe TAB_KON_583 – Default-Signaturverfahren).
    2.       Für alle Dokumente des Stapels wird die Zulässigkeit des Kartentyps geprüft. Das für die Signatur zu nutzende Zertifikat wird anhand des Kartentyps und des Parameters crypt ausgewählt.
    3.       Es werden die Voraussetzungen für die Signatur geprüft. Dies erfolgt durch Aufruf von TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“.
    4.       Zum Vorbereiten der Dokumente für die Signatur wird TUC_KON_155 „Dokumente zur Signatur vorbereiten“ mit ocspResponses aufgerufen.
    5.       Die Signaturen werden durch den Aufruf von TUC_KON_166 erstellt.
    6.       Die signierten Dokumente werden an den Aufrufer zurückgegeben.
    Varianten/
    Alternativen
    Im Fall signatureType=S/MIME-Signatur
    wird der Standardablauf des CMS Signaturverfahrens durch einen vorgelagerten S/MIME-Vorbereitungsschritt und einen nachgelagerten S/MIME-Nachbereitungsschritt ergänzt. Das S/MIME-Verfahren MUSS konform [S/MIME] und SOLL konform [COMMON_PKI], Part 3, erfolgen.
    Der S/MIME-Vorbereitungsschritt bereitet das übergebene MIME-Dokument gemäß [S/MIME], Kapitel 3.1, auf die nachfolgende CMS-Signatur durch eine Kanonisierung für Text [S/MIME], Kapitel 3.1.1, vor. Eine weitere Kanonisierung oder eine Anpassung des Transfer Encodings [S/MIME], Kapitel 3.1.2, erfolgt nicht.
    Im S/MIME-Nachbereitungsschritt wird das im Standardablauf erzeugte CMS-Objekt in eine MIME-Nachricht vom Typ „application/pkcs7-mime“ eingebettet.
    Sämtliche Header-Felder der Nachricht MÜSSEN in die Header-Felder der S/MIME-Nachricht übernommen werden.
    "MIME-Version: 1.0" MUSS definiert sein.
    Das Feld "Content-Type:" ist als "application/pkcs7-mime" zu definieren. Die weiteren Attribute dieses Feldes sind:
    • "smime-type=signed-data;"
    • "name=$dateiname", wobei $dateiname auf ".p7m" endet.
    Die Codierung des signierten Inhalts der Nachricht MUSS in "base64" erfolgen. Entsprechend ist das zugehörige Header-Feld zu füllen: "Content-Transfer-Encoding: base64".
    Das Feld "Content-Disposition" definiert den Inhalt der Nachricht als Dateianhang: "Content-Disposition: attachment; filename=$dateiname"
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
    (2) Ungültige Angabe des Signaturverfahrens: Fehlercode 4111
             Übergabe eines für die nonQES nicht unterstützten
            Dokumentformats: Fehlercode 4110
      (3) Kartentyp nicht zulässig für Signatur: Fehlercode 4126
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 210: TAB_KON_127 Fehlercodes TUC_KON_160 „Dokumente nonQES signieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4110
    Technical
    Error
    ungültiges Dokumentformat (%Format%)
    Der Parameter Format enthält das übergebene Dokumentformat.
    4111
    Technical
    Error
    ungültiger Signaturtyp oder Signaturvariante
    4126
    Security
    Error
    Kartentyp nicht zulässig für Signatur

    Die zulässigen Zertifikate und Schlüssel sind in TAB_KON_900 aufgelistet. <=

    4.1.8.4.2 TUC_KON_161 „nonQES Dokumentsignatur prüfen”

    TIP1-A_4654-04

    Der Konnektor MUSS den technischen Use Case TUC_KON_161 „nonQES Dokumentsignatur prüfen” umsetzen.

    Tabelle 211: TAB_KON_121 - TUC_KON_161 „nonQES Dokumentsignatur prüfen“

    Element
    Beschreibung
    Name
    TUC_KON_161 „nonQES Dokumentsignatur prüfen”
    Beschreibung

    Es wird die nicht-qualifizierte elektronische Signatur (nonQES) eines Dokuments geprüft. Dabei werden die Signaturverfahren laut Tabelle TAB_KON_582 – Signaturverfahren unterstützt. Sind mehrere Signaturen vorhanden, so werden alle geprüft. Auch Parallel- und Gegensignaturen MÜSSEN unterstützt werden.
    Die unterstützten Zertifikatstyp-OIDs sind in der Tabelle TAB_KON_786 aufgelistet.

    Auslöser

    Aufruf durch ein Clientsystem (Operation VerifyDocument) oder ein Fachmodul
    Vorbedingungen
    keine
    Eingangsdaten

    • signedDocument
      (Signiertes Document vom Typ nonQES_DocFormate)
    • signature – optional/falls detached Signatur
      (Signatur. Es werden Parallel- und Gegensignaturen unterstützt.)
    • optionalInputs
      (optionale Eingabeparameter, siehe Operation VerifyDocument, Parameter SIG:OptionalInputs)
    • certificate – optional/verpflichtend, wenn das Zertifikat nicht im signierten Dokument enthalten ist
      (X.509-Zertifikat, gegen das die Signatur geprüft werden soll)
    ocspGracePeriod
             (OCSP-Grace Period: maximal zulässiger Zeitraum, den die letzte
            OCSP-Antwort aus dem Cache bezüglich des Referenzzeitpunkts
            zurückliegen darf)
    • xmlSchemas – optional/nur für XML-Dokumente
      (XMLSchema und ggf. weitere vom Hauptschema benutzte Schemata)
    • includeRevocationInfo: – optional; Default = false
      (Dieser optionale Parameter steuert die Einbettung von OCSP Antworten in die Signatur)
    Komponenten
    Konnektor
    Ausgangsdaten

    • verificationResult [VerificationResult]
      (Ergebnis der Signaturprüfung)
    • optionalOutput – optional
      (weitere Ausgabedaten gemäß SIG:OptionalOutput)
    Standardablauf

    1. „DocumentValidation“:
      Falls die Signatur im Dokument eingebettet ist, wird das signierte Dokument validiert  durch Aufruf TUC_KON_080 „Dokument validieren“ { CheckDisplayability=false; … } Treten dabei Fehler bei Validierung der Typkonformität auf, wird die Prüfung mit einem Fehler abgebrochen.
    2. „CoreValidation“:
      Es erfolgt die mathematische Prüfung der Signatur bestehend aus der Prüfung der Hash-Kette bis zum signierten Hashwert und der Prüfung der kryptographischen Signatur unter Verwendung des öffentlichen Schlüssels, des Signaturwertes und des signierten Hashwertes.
    XML-Signatur:
          Die Core Validation erfolgt entsprechend [XMLDSig]
          Kapitel 3.2 Core Validation.
    CMS-Signatur:
          Die Core Validation erfolgt entsprechend Cryptographic
         Message Syntax (CMS) Kapitel 5.6 Signature Verification
         Process [RFC5652].
    PDF-Signatur:
          Die Core Validation erfolgt entsprechend [PAdES-3]
          Kapitel 4.6 Signature Validation aus PAdES-BES Part 3.
    Auch wenn die Validierung fehlschlägt, werden die folgenden Prüfschritte durchgeführt, so dass ein vollständiges Prüfprotokoll erstellt werden kann.
    1. „CheckSignatureCertificate“:
    Teil 1: Signaturzertifikat ermitteln
    XML-Signatur:
          Das Signaturzertifikat ist im XMLDSig Element
         ds:KeyInfo/ds:X509Data gespeichert [XMLDSig]
         oder wird als Eingangsparameter übergeben.
    CMS-Signatur:
          Das Signaturzertifikat für CAdES ist im Feld
         certificates im SignedData Container gespeichert
         [CAdES] oder wird als Eingangsparameter übergeben.
    PDF-Signatur:
          Das PDF Signaturzertifikat für PAdES ist im Feld
         SignedData.certificates entsprechend Kapitel 6.1.1
          „Placements of the signing certificate“
          [PAdES Baseline Profile] gespeichert oder wird als
         Eingangsparameter übergeben.
    Teil 2: Signaturzeitpunkt bestimmen
    Der Signaturzeitpunkt Ermittelter_Signaturzeitpunkt_Eingebettet wird wie folgt selektiert:
    XML-Signatur:
    Das XML element SigningTime spezifiziert den 
    Signaturzeitpunkt entsprechend Kapitel 7.2.1 XAdES
    [XAdES].
    CMS-Signatur:
    Das Attribut SigningTime spezifiziert den
    Signaturzeitpunkt entsprechend Kapitel 11.3 CMS [CMS].
    PDF-Signatur:
    Der Signaturzeitpunkt kann dem M Eintrag des Signature
    Dictionary entnommen werden [PAdES Baseline Profile]
    Kapitel 6.2.1 Signing time.
    Der Signaturzeitpunkt Benutzerdefinierter_Zeitpunkt liegt gegebenenfalls als Aufrufparameter vor. Der Signaturzeitpunkt Ermittelter_Signaturzeitpunkt_System wird ermittelt.

    Teil 3: Signaturzertifikatsprüfung:
    Bei der folgenden Signaturzertifikatsprüfung sind die Signaturzeitpunkte gemäß [TIP1-A_5545] zu berücksichtigen.
    Die Signaturzertifikatsprüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“.
    Die Parameter im Aufruf von TUC_KON_037 „Zertifikat prüfen“ werden wie folgt gesetzt
    • certificate = certificate;
    • qualifiedCheck = not_required;
    • baseTime = Signaturzeitpunkt;
    • offlineAllowNoCheck = true;
    • ocspResponses = OCSP-Response;
    • gracePeriod = ocspGracePeriod;
    • validationMode = OCSP;
    • getOCSPResponses = includeRevocationInfo
    In Abhängigkeit von der policyList gemäß Tabelle TAB_KON_786 gesetzte Parameter:
    • policyList;
    • intendedKeyUsage;
    • ggf. intendedExtendedKeyUsage;
    Sind OCSP-Responses in der Signatur eingebettet, ist die jüngste OCSP-Response, die für die Zertifikatsprüfung notwendig ist, beim Aufruf von TUC_KON_037 zu übergeben.
    Sofern der Aufruf von TUC_KON_037 ocspResponsesRenewed zurückgibt, wird die Liste der OCSP-Responses in die Signatur eingebettet.
    Auch wenn die Zertifikatsprüfung fehlschlägt, werden die folgenden Prüfungen durchgeführt.
    1. “CheckPolicyConstraints“
    In diesem Schritt wird das signierte Dokument entsprechend der Profilierung der Signaturformate (siehe Anhang B.2) geprüft.
    Es sind die Vorgaben für die Prüfung von Signaturen aus den Standards für AdES [XAdES], [XAdES Baseline], [CAdES], [CAdES Baseline], [PAdES-3] und [PAdES Baseline] umzusetzen. Dabei sind die Vorgaben aus Tabelle TAB_KON_779-01 „Profilierung der Signaturformate“ und Tabelle
    TAB_KON_778 „Einsatzbereich der Signaturvarianten“ zu erfüllen.

    Auch wenn nicht alle Anforderungen an das Format des signierten Dokuments erfüllt werden, wird die Prüfung mit den folgenden Schritten fortgesetzt, um ein vollständiges Prüfungsprotokoll zu erhalten.
    1. Das Prüfergebnis (verificationResult, optionalOutput wird an den Aufrufer zurückgegeben (siehe TAB_KON_754 Übersicht Status für Prüfung einer Dokumentensignatur).
    Varianten/
    Alternativen

    Im Fall, dass die Online-Prüfung des Sperrzustands des Signaturzertifikats nicht möglich ist und eine möglicherweise gecachte OCSP-Response nicht vorhanden ist oder nicht mehr verwendet werden darf, wird das Prüfergebnis mit der entsprechenden Warnung zurückgegeben.
    Im Fall einer PKCS#1-Signatur ist das verwendete Signaturverfahren,  RSASSA-PSS bzw. RSASSA-PKCS1-v1_5, aus der Signatur zu bestimmen.
    Fehlerfälle

    Das Verhalten des TUCs bei einem Fehlerfall ist in TAB_KON_124 Fehlercodes TUC_KON_161 „nonQES Dokumentensignatur prüfen“ beschrieben.
    (->1) keine Signatur in signedDocument und signature vorhanden: 4253
    (2 „CoreValidation“)
    Interner Fehler: 4001, Signatur des Dokument ungültig: 4115.
    Signatur umfasst nicht das gesamte Dokument: 4262.
    (3 „CheckSignatureCertificate“)      
    Interner Fehler: 4001, Signaturzertifikat ermitteln fehlgeschlagen: 4206.
    (4 „CheckPolicyConstraints“)  
    Interner Fehler: 4001, Dokument nicht konform zu Regeln für nonQES: 4112.
    Nichtfunktionale Anforderungen
    keine

    Zugehörige Diagramme
    keine

    Tabelle 212: TAB_KON_124 Fehlercodes TUC_KON_161 „nonQES Dokumentensignatur prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten.
    4001
    Technical
    Error
    Interner Fehler
    4206
    Technical
    Error
    Signaturzertifikat ermitteln ist fehlgeschlagen
    4112
    Technical
    Error
    Dokument nicht konform zu Regeln für nonQES
    4115
    Security
    Error
    Signatur des Dokuments ungültig.
    Der SignatureValue des Dokuments ist falsch oder für mindestens eine Reference ist der DigestValue falsch.
    4253
    Technical
    Error
    Keine Signatur im Aufruf
    4262 Technical Error Signatur umfasst nicht das gesamte Dokument
    4264 Technical Warning Ein oder mehrere Zertifikate ignoriert
    Das Gesamtergebnis (VerificationResult) für die Prüfung einer Dokumentensignatur fasst die Ergebnisse aller Prüfungsschritte in einem einzelnen Statuswert zusammen.

    Tabelle 213: TAB_KON_754 Übersicht Status für Prüfung einer Dokumentensignatur

    VerificationResult für gesamtes Dokument (VerificationResult/HighLevelResult)
    Wert
    Bedeutung
    VALID
    Wenn VerificationResult für alle Signaturen zum Dokument VALID
    INVALID
    Wenn VerificationResult für eine Signatur zum Dokument INVALID
    INCONCLUSIVE
    in allen anderen Fällen
    VerificationResult pro Signatur  (VerificationReport/IndividualReport/Result)
    Wert
    Bedeutung
    mögliche Ausprägungen im VerificationReport
    VALID
    Die Signatur wurde gemäß den Regeln für die nonQES geprüft und für gültig befunden.
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:OnAllDocuments
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:HasManifestResults
    INVALID
    Die Signatur ist ungültig oder aufgrund eines Fehlers konnte die Signaturprüfung nicht durchgeführt werden.
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:CertificateChainNotComplete
    INCONCLUSIVE
    Die Signatur wurde gemäß den Regeln für die nonQES geprüft. Allerdings konnten eine oder mehrere Prüfungen nicht vollständig durchgeführt werden. Einzelheiten finden sich in Result-Detail.
    Die Prüfungen, die durchgeführt werden konnten, waren erfolgreich.
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:OcspNotAvailiable

    Hinweis: Das Erreichen dieses Zustandes hängt davon ab, ob eine OCSP-Abfrage nicht durchgeführt werden konnte, unabhängig davon, ob die Ursache dafür die Offlineschaltung des Konnektors (MGM_LU_ONLINE = Disabled) oder die Nichterreichbarkeit des OCSP-Responders im Online-Betrieb (MGM_LU_ONLINE = Enabled)  ist.

    Tabelle 214: TAB_KON_786 Übersicht unterstützte Zertifikatstyp-OIDs

    policyList intendedKeyUsage intendedExtendedKeyUsage
    X.509-Zertifikat einer eGK oid_egk_aut intendedKeyUsage(C.CH.AUT) id-kp-clientAuth
    X.509-Zertifikat einer eGK oid_egk_autn intendedKeyUsage(C.CH.AUTN) id-kp-clientAuth
    X.509-Zertifikat der SM-B oid_smc_b_osig intendedKeyUsage(C.HCI.OSIG) -
    X.509-Zertifikat eines fachanwendungsspezifischen Dienstes oid_fd_sig intendedKeyUsage(C.FD.SIG) -
    X.509-Zertifikat eines fachanwendungsspezifischen Dienstes (nonRepudiation) oid_fd_osig intendedKeyUsage(C.FD.OSIG) -
    X.509-Zertifikat eines zentralen Dienstes (nonRepudiation) oid_zd_sig intendedKeyUsage(C.ZD.SIG) -
    <=

    TIP1-A_5545

    Der Konnektor MUSS zur nonQES-Signaturprüfung ein Prüfergebnis das sich auf genau einen angenommenen Signaturzeitpunkt bezieht, an den Aufrufer zurückgeben.
    Die Auswahl des angenommenen Signaturzeitpunkts, auf den sich das Signaturergebnis bezieht, erfolgt hierarchisch:

    <=

    4.1.8.4.3 TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur”

    TIP1-A_5505

    Der Konnektor MUSS den technischen Use Case TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur” umsetzen.

    Tabelle 215: TAB_KON_430 – TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“

    Element
    Beschreibung
    Name
    TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur”
    Beschreibung
    Es wird die mathematische Korrektheit der elektronischen Signatur eines XML-Dokuments geprüft. Sind mehrere Signaturen vorhanden, so werden alle geprüft.
    Auslöser
    Aufruf durch ein Fachmodul
    Vorbedingungen
    • signedDocument ist ein XML-Dokument
    • signedDocument  hat TUC_KON_080 erfolgreich durchlaufen
    Eingangsdaten
    • signedDocument – optional
      (QES-signiertes XML-Dokument
      -> siehe Definition in Operation VerifyDocument mit
      SIG:Document)
    • signatureObject– optional
      ( -> siehe Definition in Operation VerifyDocument mit
      dss:SignatureObject)
    Komponenten
    Konnektor
    Ausgangsdaten
    • result
      (Ergebnis der Signaturprüfung)

    Standardablauf
    „CoreValidation“:
    Es erfolgt die mathematische Prüfung der Signatur, bestehend aus der Prüfung der Hash-Kette bis zum signierten Hashwert und der Prüfung der kryptographischen Signatur unter Verwendung des öffentlichen Schlüssels aus dem Zertifikat, des Signaturwertes und des signierten Hashwertes.
    XML-Signatur:
          Die Core Validation erfolgt entsprechend [XMLDSig] Kapitel 3.2
         Core Validation.

      a) CoreValidation erfolgreich -> result = true
      b) CoreValidation fehlerhaft  -> result = false
    Varianten/Alternativen
    keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zu den ausgewiesenen Fehlercodes:
    Interner Fehler: 4001
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 216: TAB_KON_431 Fehlercodes TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weiteren Fehlercodes auftreten.
    4001
    Technical
    Error
    Interner Fehler

    <=

    4.1.8.4.4 TUC_KON_150 „Dokumente QES signieren”

    TIP1-A_4655-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_150 „Dokumente QES signieren” umsetzen.

    Tabelle 217: TAB_KON_755 – TUC_KON_150 „Dokumente QES signieren“

    Element
    Beschreibung
    Name
    TUC_KON_150 ”Dokumente QES signieren”
    Beschreibung


    Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer qualifizierten elektronischen Signatur versehen. Es werden die QES_DocFormate unterstützt.
    Auslöser
    Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul.
    Vorbedingungen
    Die Signaturkarte muss gesteckt sein.
    Eingangsdaten


    • signRequests
      (Liste von Signaturaufträgen)
      Jeder Signaturauftrag (SignRequest) kapselt:
      • documentsToBeSigned
        (Zu signierendes Dokument bzw. zu signierende Dokumente);
        darin u.a.
        documentFormat
        (Formatangabe für das zu signierende Dokument)
      • optionalInputs
        (weitere optionale Eingabeparameter zur Steuerung der Details bei der zu erstellenden Signatur, siehe Operation SignDocument, Parameter dss:OptionalInputs); darin u.a. signatureType (URI für den Signaturtyp  XML-, CMS-, S/MIME-, PDF-Signatur)
      • includeRevocationInfo [Boolean]: – optional; Default: true
        (Dieser optionale Parameter steuert die Einbettung von OCSP Antworten in die Signatur; siehe Operation SignDocument, Parameter SIG:IncludeRevocationInfo)
    • cardSession
      (Kartensitzung. Unterstützte Kartentypen: HBAx)
    • crypt [SIG_CRYPT_QES] - optional;
      default und Wertebereich: siehe TAB_KON_862-01
      (Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)
    • workplaceId
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte (HBAx)
    Ausgangsdaten
    • signedDocuments
      (Liste der signierten Dokumente
    Standardablauf


    Der Konnektor KANN die Schritte 1 bis 4 in einer beliebigen Reihenfolge durchführen.
    1. Der Signaturtyp und die Signaturvariante werden für jedes Dokument der Liste entsprechend signatureType und SignatureVariant festgelegt (ggf. in optionalInputs enthalten). Wenn SignatureType oder SignatureVariant nicht übergeben wurden, wird das dem Dokumentformat entsprechende Default-Verfahren gewählt (siehe TAB_KON_583 – Default-Signaturverfahren).
    2. Für alle Dokumente des Stapels wird die Zulässigkeit des Kartentyps geprüft. Das für die Signatur zu nutzende Zertifikat wird anhand des Kartentyps und des Parameters crypt  ausgewählt.
    3. Es werden die Voraussetzungen für die Signatur geprüft. Dies erfolgt im TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“.
      Wenn includeRevocationInfo=true, dann setze ocspResponses auf Rückgabewert von TUC_KON_152.
    4. Die am Signaturvorgang beteiligten Ressourcen (Signaturkarte sowie PIN Pad und Display des PIN-Eingabe-Kartenterminals) werden für die exklusive Nutzung durch diesen Signaturvorgang reserviert. Die Reservierung der Signaturkarte erfolgt durch Aufruf von
      TUC_KON_023 „Karte reservieren“ {
          cardSession;
          doLock = true }.
    5. Zum Vorbereiten der Dokumente für die Signatur wird TUC_KON_155 „Dokumente zur Signatur vorbereiten“ mit ocspResponses aufgerufen.
      Die Zugriffe auf die Signaturkarte in den Schritten 6 bis 7 müssen im DF.QES erfolgen.
    6. Die Signaturerstellung wird durch den Anwender autorisiert. Dies erfolgt durch Aufruf von TUC_KON_012 „PIN verifizieren“ { cardSession;
      workplaceId;
      pinRef = PIN.QES;
      verificationType = Mandatorisch }
    Wenn nur ein zu signierendes Dokument vorhanden ist und der Einfachsignaturmodus aktiviert ist (siehe Konfigurationsparameter SAK_SIMPLE_SIGNATURE_ MODE), wird in Schritt 7 Variante a) durchgeführt, ansonsten Variante b).
    1. Variante a) Die Signatur wird erstellt. Dies erfolgt gemäß TUC_KON_168 „Einzelsignatur QES erstellen“.
      Variante b) Die Signaturen werden erstellt. Dies erfolgt gemäß TUC_KON_154 „QES-Signaturen erstellen“.
    2. Es wird DF.QES verlassen, um den PIN-Status der PIN.QES zurückzusetzen. Der im Konnektor verwaltetete Sicherheitszustand (CARDSESSION.AUTHSTATE) ist zu aktualisieren.
    3. Die reservierten Ressourcen (Signaturkarte sowie PIN-Pad und
      Display des PIN-Eingabe-Kartenterminals) werden wieder freigegeben.
      Zur Freigabe der Signaturkarte wird TUC_KON_023 „Karte reservieren“ 
         cardSession;
         doLock = false }
      aufgerufen.
    4. Die signierten Dokumente werden an den Aufrufer zurückgegeben.
    Varianten/
    Alternativen
    Der Nutzer kann den Vorgang bei der Autorisierung (Schritt 6) abbrechen. Hierbei sind die gleichen Regeln anzuwenden wie im Fehlerfall (s. Fehlerfälle).
    Fehlerfälle


    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
    (->1) Ungültige Angabe des Signaturtyps oder Signaturvariante:
             Fehlercode 4111
             Übergabe eines für die QES nicht unterstützten Dokumentformats:
             Fehlercode 4110
    (->2) Kartentyp nicht zulässig für Signatur: Fehlercode 4126
    (->5) Fehler bei der Reservierung von Ressourcen: Fehlercode 4060
    (->7b) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4118
    Im Fehlerfall, inklusive Timeout bei der PIN-Eingabe, oder bei Abbruch durch den Benutzer (Fehler 4049):
     a)      … MUSS DF.QES verlassen werden
     b)      … MÜSSEN alle reservierten Ressourcen freigegeben werden
     c)      … MUSS der Fehler immer an das Clientsystem zurückgemeldet
        werden
    Nichtfunktionale Anforderungen
    keine

    Zugehörige Diagramme
    Abbildung PIC_KON_114 Aktivitätsdiagramm zu „Dokument QES signieren“



    Abbildung 19: PIC_KON_114 Aktivitätsdiagramm zu „Dokument QES signieren“


    Tabelle 218: TAB_KON_128 Fehlercodes TUC_KON_150 „Dokument QES signieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4060
    Technical
    Error
    Ressource belegt
    4110
    Technical
    Error
    ungültiges Dokumentformat (%Format%)
    Der Parameter Format enthält das übergebene Dokumentformat.
    4111
    Technical
    Error
    ungültiger Signaturtyp oder Signaturvariante
    4118
    Technical
    Error
    Stapelsignaturen werden nur für den HBA unterstützt. Mit HBA-Vorläuferkarten sind nur Einzelsignaturen möglich.
    4126
    Security
    Error
    Kartentyp nicht zulässig für Signatur
    4049
    Technical
    Error
    Abbruch durch den Benutzer
    <=

    4.1.8.4.5 Anforderungen an die Stapelsignatur

    Eine Stapelsignatur definiert sich als „Erstellung einer begrenzten Anzahl Signaturen nach den zeitlich unmittelbar aufeinander folgenden Prozessen der Anzeige der zu signierenden Daten und der einmaligen Authentisierung des Signaturschlüssel-Inhabers gegenüber der qualifizierten elektronischen Signaturerstellungseinheit“ (siehe [BSI-TR03114]).

    TIP1-A_4669

    Der Signaturdienst MUSS die Möglichkeit bieten, Dokumente eines Stapels einzeln qualifiziert elektronisch zu signieren. Der Signaturdienst MUSS als qualifizierte elektronische Signaturerstellungseinheit für die Stapelsignatur den HBA unterstützen.

    <=

    TIP1-A_5664

    Die zu signierenden Dokumente einer Stapelsignatur MÜSSEN vom Signaturdienst im Konnektor in derselben Reihenfolge signiert, in der sie im Signaturauftrag vom Clientsystem geschickt werden.

    <=

    TIP1-A_4670

    Bei der Stapelsignatur MUSS der Signaturdienst die zu signierenden Daten (DTBS) über Secure Messaging vom Konnektor zum HBA übertragen. Dieser Secure Messaging-Kanal MUSS über die gSMC-K zum HBA mittels C.SAK.AUTD_CVC aufgebaut werden.

    <=

    TIP1-A_4671

    Der Signaturdienst MUSS dem Benutzer während und nach einer PIN-Eingabe die Möglichkeit zum Abbruch einer Stapelsignatur anbieten.
    Das geforderte Verhalten des Konnektors beim Abbruch einer Stapelsignatur wird in der folgenden Tabelle beschrieben. Hierbei werden die beiden Punkte „Abbruch, während die erneute PIN-Eingabe angefordert wird“ (Nummer 1 bis 4) und „Abbruch, während der Vorgang der Signaturerstellung läuft“ (Nummer 5 bis 6) unterschieden. Zeile Nummer 7 beschreibt alle sonstigen Fehlerfälle.
    Ein Teilstapel einer Stapelsignatur ist durch die maximale Anzahl der Dokumente definiert, welche nach der Eingabe der Signatur-PIN durch den Signaturschlüssel-Inhaber signiert werden kann.

    Tabelle 219: TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur

    Nummer
    Problem/Fehler/Ereignis
    Verhalten des Konnektors
    Während die erneute PIN-Eingabe angefordert wird
    1
    Timeout bei der PIN-Eingabe am KT
    Der Signaturvorgang (Stapel) wird beendet:
    Kein „Fehler“
    Die Signaturen des/der vorherigen Teilstapel(s) bleiben erhalten und werden an das Clientsystem zurückgegeben.
    Keine weiteren Signaturen des neuen Teilstapels werden erstellt. (Die Weiterverarbeitung bereits erstellter Signaturen des letzten Teilstapels (sofern vorhanden) wird noch abgeschlossen).
    2
    PIN gesperrt (nach mehrfacher Fehleingabe)
    Siehe Verhalten unter Nummer 1
    3
    Abbruchkommando „StopSignature“ zur Jobnummer wird empfangen

    Der Signaturvorgang (Stapel) wird beendet.
    Kein „Fehler“
    Keine weiteren Signaturen des neuen Teilstapels werden erstellt. (Die Weiterverarbeitung bereits erstellter Signaturen des letzten Teilstapels (sofern vorhanden) wird noch abgeschlossen).
    4
    Abbruchtaste am Kartenterminal wird gedrückt
    Siehe Verhalten unter Nummer 1
    während der Vorgang der Signaturerstellung läuft
    5
    Abbruchkommando „StopSignature“ zur Jobnummer wird empfangen

    Signaturvorgang (Stapel) wird abgebrochen.
    Kein „Fehler“
    Keine weiteren Signaturen des Stapels werden erstellt.
    Keine weiteren Signaturen des Teilstapels werden erstellt.
    Bisher erstellte Signaturen des aktuellen Teilstapels werden verworfen.
    6
    Abbruchtaste am Kartenterminal wird gedrückt.
    Die „Abbruch“-Taste wird nicht vom Signaturdienst fortlaufend überwacht Keine Aktion seitens des Signaturdienstes.

    7
    Bei allen anderen Fehlerfällen (z. B.: es kommen zu viele Signaturen zurück, der Hash-Wert einer der Signaturen stimmt nicht, Karte gezogen, etc)
    Signaturvorgang (Stapel) wird abgebrochen.
    Schwerer Fehler.
    Keine weiteren Signaturen des Stapels werden erstellt.
    Keine weiteren Signaturen des aktuellen Teilstapels werden erstellt.
    Bisher erstellte Signaturen aller Teilstapel werden verworfen.
    Es handelt sich um Probleme/Fehlerfälle, die bei typischen Angriffen auftreten können.

    <=

    4.1.8.4.6 TUC_KON_151 „QES Dokumentensignatur prüfen“

    TIP1-A_4672-04

    Der Konnektor MUSS den technischen Use Case TUC_KON_151 „QES-Dokumentensignatur prüfen” umsetzen.

    Tabelle 220: TAB_KON_591 - TUC_KON_151 „QES-Dokumentensignatur prüfen“

    Element
    Beschreibung
    Name
    TUC_KON_151 „QES-Dokumentensignatur prüfen”
    Beschreibung
    Es wird die QES eines Dokuments geprüft. Dabei werden die Signaturverfahren laut Tabelle TAB_KON_582 – Signaturverfahren unterstützt. Sind mehrere Signaturen vorhanden, so werden alle geprüft. Auch Parallel- und Gegensignaturen MÜSSEN unterstützt werden.
    Eingangsanforderung
    keine
    Auslöser
    Aufruf durch ein Clientsystem (Operation VerifyDocument) oder durch ein Fachmodul im Konnektor
    Vorbedingungen
    keine
    Eingangsdaten
    • signedDocument – optional
      (QES-signiertes Dokument vom Typ
      QES_DocFormate
      -> siehe Definition in Operation VerifyDocument mit SIG:Document)
    • signatureObject – optional
      ( -> siehe Definition in Operation VerifyDocument mit dss:SignatureObject.
      Es werden Parallel- und Gegensignaturen unterstützt.)

    • optionalInputParams
      (optionale Eingabeparameter, siehe Operation VerifyDocument, Parameter SIG:OptionalInputs)

    • certificates – optional/falls diese nicht im signierten Dokument enthalten sind, sondern nur referenziert werden
      (X.509-Zertifikate ).
    • xmlSchemas – optional/nur für XML-Dokumente
      (XMLSchema und ggf. weitere vom Hauptschema benutzte Schemata)

    • includeRevocationInfo [Boolean]: – optional; Default: false
      (Dieser optionale Parameter steuert die Einbettung von OCSP Antworten in die Signatur)

    Komponenten
    Konnektor
    Ausgangsdaten
    • verificationResult [VerificationResult]
      (Ergebnis der Signaturprüfung)

    • optionalOutput – optional
      (weitere Ausgabedaten gemäß SIG:OptionalOutput)

    Standardablauf
    1. „DocumentValidation“: Das signierte Dokument wird validiert mit Aufruf TUC_KON_080 „Dokument validieren“{ … }.

    Treten Fehler bei der Validierung der Typkonformität auf, wenn die Signatur im Dokument eingebettet ist, wird die Prüfung mit einem Fehler abgebrochen.
    Treten bei der Typkonformität, wenn die Signatur nicht im Dokument eingebettet ist, Fehler auf, so bricht der TUC nicht ab, sondern führt die folgenden Schritte soweit sinnvoll möglich durch. (Die Entscheidung über das sinnvoll Durchführbare liegt beim Hersteller des Konnektors.)


    2. „CoreValidation“:
    Es erfolgt die mathematische Prüfung der Signatur, bestehend aus der Prüfung der Hash-Kette bis zum signierten Hashwert und der Prüfung der Signatur unter Verwendung des öffentlichen Schlüssels, des Signaturwertes und des signierten Hashwertes.

    XML-Signatur:
    Die Core Validation erfolgt entsprechend [XMLDSig] Kapitel 3.2 Core Validation.
    CMS-Signatur: 
    Die Core Validation erfolgt entsprechend Cryptographic Message Syntax (CMS) Kapitel 5.6 Signature Verification Process [RFC5652].
    PDF-Signatur:
    Die Core Validation erfolgt entsprechend [PAdES-3] Kapitel 4.6 Signature Validation aus PAdES-BES Part 3.

    Auch wenn die Validierung fehlschlägt, werden die folgenden Prüfschritte durchgeführt, so dass ein vollständiges Prüfprotokoll erstellt werden kann.

    3. „CheckSignatureCertificate“:

    Teil 1: Signaturzertifikat ermitteln
      XML-Signatur:
            Das Signaturzertifikat ist im XMLDSig Element
            ds:KeyInfo/ds:X509Data gespeichert [XMLDSig] oder wird als
            Eingangsparameter übergeben.
      CMS-Signatur:
            Das Signaturzertifikat für CAdES ist im Feld certificates im
           SignedData Container gespeichert [CAdES] oder wird als
           Eingangsparameter übergeben.
      PDF-Signatur:
            Das PDF Signaturzertifikat für PAdES ist im Feld
           SignedData.certificates entsprechend Kapitel 6.1.1 „Placements of
           the signing certificate“ [PAdES Baseline Profile] gespeichert oder
           wird als Eingangsparameter übergeben.

    Teil 2: Signaturzeitpunkt bestimmen

      Der Signaturzeitpunkt
     Ermittelter_Signaturzeitpunkt_Eingebettet wird wie
      folgt selektiert:
      XML-Signatur:
           Das XML element SigningTime spezifiziert den Signaturzeitpunkt
           entsprechend Kapitel 7.2.1 XAdES [XAdES].
      CMS-Signatur:
           Das Attribut SigningTime spezifiziert den Signaturzeitpunkt
           entsprechend Kapitel 11.3 CMS [CMS].
      PDF-Signatur:
           Der Signaturzeitpunkt kann dem M Eintrag des Signature Dictionary
           entnommen werden [PAdES Baseline Profile] Kapitel 6.2.1 Signing
           time.

    Der Signaturzeitpunkt Benutzerdefinierter_Zeitpunkt liegt gegebenenfalls als Aufrufparameter vor. Der Signaturzeitpunkt Ermittelter_Signaturzeitpunkt_System wird ermittelt.

    Teil 3: Signaturzertifikatsprüfung:
    Bei der folgenden Signaturzertifikatsprüfung sind die Signaturzeitpunkte gemäß [TIP1-A_5540] zu berücksichtigen.
    Die Signaturzertifikatsprüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ {
        certificate = C.HP.QES;
        qualifiedCheck = required;
        baseTime = Signaturzeitpunkt;
        offlineAllowNoCheck = true;
       validationMode = OCSP;
        ocspResponses = OCSP-Response;
        getOCSPResponses = includeRevocationInfo
    }.
    Sind OCSP-Responses in der Signatur eingebettet, ist die jüngsten OCSP-Response des EE-Zertifikats, die für die Zertifikatsprüfung notwendig ist, beim Aufruf von TUC_KON_037 zu übergeben.
    Sofern der Aufruf von TUC_KON_037 ocspResponses zurückgibt, wird die OCSP-Response des EE-Zertifikats in die Signatur eingebettet.
    Auch wenn die Zertifikatsprüfung fehlschlägt, werden die folgenden Prüfungen durchgeführt.

    4. „CheckPolicyConstraints“:

    In diesem Schritt wird das signierte Dokument entsprechend der Profilierung der Signaturformate (siehe Anhang B.2) geprüft. Es sind die Vorgaben für die Prüfung von Signaturen aus den Standards für AdES [XAdES], [XAdES Baseline], [CAdES], [CAdES Baseline], [PAdES-3] und [PAdES Baseline] umzusetzen. Dabei sind die Vorgaben aus Tabelle TAB_KON_779-01
    "Profilierung der Signaturformate“ und Tabelle TAB_KON_778 „Einsatzbereich der Signaturvarianten“ zu erfüllen.

    Auch wenn nicht alle Anforderungen an das Format des signierten Dokuments erfüllt werden, wird die Prüfung mit den folgenden Schritten fortgesetzt, um ein vollständiges Prüfungsprotokoll zu erhalten.

    5. Das Prüfergebnis (VerificationResult, OptionalOutput) wird an den Aufrufer zurückgegeben (siehe TAB_KON_593 Übersicht Status für Prüfung einer Dokumentensignatur).

    Varianten/Alternativen
    Keine
    Fehlerfälle
    Das Verhalten des TUCs bei einem Fehlerfall ist in TAB_KON_592 Fehlercodes TUC_KON_151 „QES Dokumentensignatur prüfen“ beschrieben.
    (->1) keine Signatur in signedDocument und signatureObject vorhanden: 4253.
    ( 2 „CoreValidation“) Interner Fehler: 4001, Signatur des Dokuments ungültig: 4115, Signatur umfasst nicht das gesamte Dokument: 4262
    (3 „CheckSignatureCertificate“) Interner Fehler: 4001, Signaturzertifikat ermitteln ist fehlgeschlagen: 4206.
    (4 „CheckPolicyConstraints“) Interner Fehler: 4001, Dokument nicht konform zu Regeln für QES: 4124, Dokument nicht konform zu Profilierung der Signaturformate: 4208.
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    keine


    Tabelle 221: TAB_KON_592 Fehlercodes TUC_KON_151 „QES Dokumentensignatur prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4001
    Technical
    Error
    interner Fehler
    4115
    Security
    Error
    Signatur des Dokuments ungültig. Prüfung der Hashwertkette bzw. Prüfung der kryptographischen Signatur fehlgeschlagen.
    4124
    Technical
    Error
    Dokument nicht konform zu Regeln für QES
    4206
    Technical
    Error
    Signaturzertifikat ermitteln ist fehlgeschlagen
    4208
    Technical
    Error
    Dokument nicht konform zu Profilierung der Signaturformate
    4253 Technical Error Keine Signatur im Aufruf
    4262 Technical Error Signatur umfasst nicht das gesamte Dokument
    4264 Technical Warning Ein oder mehrere Zertifikate ignoriert
    Das Gesamtergebnis (VerificationResult) für die Prüfung einer Dokumentensignatur fasst die Ergebnisse
    aller Prüfungsschritte in einem einzelnen Statuswert zusammen. 

    Tabelle 222: TAB_KON_593 Übersicht Status für Prüfung einer Dokumentensignatur

    VerificationResult für gesamtes Dokument (VerificationResult/HighLevelResult)
    Wert
    Bedeutung
    VALID
    Wenn VerificationResult für alle Signaturen zum Dokument VALID
    INVALID
    Wenn VerificationResult für eine Signatur zum Dokument INVALID
    INCONCLUSIVE
    in allen anderen Fällen
    VerificationResult pro Signatur  (VerificationReport/IndividualReport/Result)
    Wert Bedeutung
    mögliche Ausprägungen im VerificationReport
    VALID Die Signatur wurde gemäß den Regeln für die QES geprüft und für gültig befunden.
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:OnAllDocuments
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:HasManifestResults
    INVALID Die Signatur ist ungültig oder aufgrund eines Fehlers konnte die Signaturprüfung nicht durchgeführt werden.
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:Success
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:CertificateChainNotComplete
    INCONCLUSIVE Die Signatur wurde gemäß den Regeln für die QES geprüft. Allerdings konnten eine oder mehrere Prüfungen nicht vollständig durchgeführt werden. Einzelheiten finden sich in Result-Detail.
    Die Prüfungen, die durchgeführt werden konnten, waren erfolgreich.
    ResultMajor = urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation
    ResultMinor = urn:oasis:names:tc:dss:1.0:resultminor:OcspNotAvailiable

    Hinweis: Das Erreichen dieses Zustandes hängt davon ab, ob eine OCSP-Abfrage nicht durchgeführt werden konnte, unabhängig davon, ob die Ursache dafür die Offlineschaltung des Konnektors (MGM_LU_ONLINE = Disabled) oder die Nichterreichbarkeit des OCSP-Responders im Online-Betrieb (MGM_LU_ONLINE = Enabled)  ist.

    <=

    TIP1-A_5540-01

    Der Konnektor MUSS zur QES-Signaturprüfung ein Prüfergebnis, das sich auf genau einen angenommenen Signaturzeitpunkt bezieht, an den Aufrufer zurückgeben.  
    Die Auswahl des angenommenen Signaturzeitpunkts, auf den sich das Signaturergebnis bezieht, erfolgt hierarchisch:

    <=

    4.1.8.4.7 TUC_KON_170 „Dokumente mit Komfort signieren”

    A_19103-06

    Der Konnektor MUSS den technischen Use Case TUC_KON_170 „Dokumente mit Komfort signieren” umsetzen.

    Tabelle 223: TAB_KON_871 – TUC_KON_170 „Dokumente mit Komfort signieren“

    Element
    Beschreibung
    Name
    TUC_KON_170 ”Dokumente mit Komfort signieren”
    Beschreibung
    Im Rahmen von Fachanwendungen werden ein oder mehrere Dokumente mit einer Komfortsignatur versehen. Es werden die QES_DocFormate unterstützt.
    Auslöser

    Aufruf durch ein Clientsystem (Operation SignDocument) oder ein Fachmodul.
    Vorbedingungen
    Die Signaturkarte muss gesteckt sein.
    Eingangsdaten



    ·         signRequests
    (Liste von Signaturaufträgen)
    Jeder Signaturauftrag (SignRequest) kapselt:
          documentsToBeSigned
    (Zu signierendes Dokument bzw. zu signierende Dokumente);
    darin u.a.
    documentFormat
    (Formatangabe für das zu signierende Dokument)
          optionalInputs
    (weitere optionale Eingabeparameter zur Steuerung der Details bei der zu erstellenden Signatur, siehe Operation SignDocument, Parameter dss:OptionalInputs); darin u.a. signatureType (URI für den Signaturtyp  XML-, CMS-, PDF-Signatur)
          includeRevocationInfo [Boolean]: – optional; Default: true
    (Dieser optionale Parameter steuert die Einbettung von OCSP Antworten in die Signatur; siehe Operation SignDocument, Parameter SIG:IncludeRevocationInfo)
    ·         cardSession
    (Kartensitzung. Unterstützte Kartentypen: HBA)
    ·         crypt [SIG_CRYPT_QES] - optional ;
    default und Wertebereich: siehe TAB_KON_862-01
    (Dieser Parameter steuert, ob RSA-basierte oder ECC-basierte Signaturen erzeugt werden.)
    ·         workplaceId
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte (HBA)
    Ausgangsdaten


    ·         signedDocuments
    (Liste der signierten Dokumente)
    Standardablauf



    Der Konnektor KANN die Schritte 1 bis 5 in einer beliebigen Reihenfolge durchführen.
    1.    Prüfe SAK_COMFORT_SIGNATURE = Enabled
    2.  Prüfe, ob der Komfortsignatur-Timer der cardSession (SAK_COMFORT_SIGNATURE_TIMER) abgelaufen ist.  
    3.    Der Signaturtyp und die Signaturvariante werden für jedes Dokument der Liste entsprechend signatureType und SignatureVariant festgelegt (ggf. in optionalInputs enthalten). Wenn SignatureType oder SignatureVariant nicht übergeben wurden, wird das dem Dokumentformat entsprechende Default-Verfahren gewählt (siehe TAB_KON_583 – Default-Signaturverfahren).
    4.    Für alle Dokumente des Stapels wird die Zulässigkeit des Kartentyps geprüft. Das für die Signatur zu nutzende Zertifikat wird anhand des Kartentyps und des Parameters crypt ausgewählt.
    5.    Es werden die Voraussetzungen für die Signatur geprüft. Dies erfolgt im TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“.
    Wenn includeRevocationInfo=true, dann setze ocspResponses auf Rückgabewert von TUC_KON_152.
    6.    Die am Signaturvorgang beteiligte RessourceSignaturkarte wird für die exklusive Nutzung durch diesen Signaturvorgang reserviert. Die Reservierung der Signaturkarte erfolgt durch Aufruf von
    TUC_KON_023 „Karte reservieren“ {
        cardSession;
        doLock = true }.
    7.    Zum Vorbereiten der Dokumente für die Signatur wird TUC_KON_155 „Dokumente zur Signatur vorbereiten“ mit ocspResponses aufgerufen.

    Die Zugriffe auf die Signaturkarte im Schritt 8 müssen im DF.QES erfolgen. DF.QES darf am Ende des TUCs nicht verlassen werden.

    8.    Die Signaturen werden erstellt. Dies erfolgt gemäß TUC_KON_158 „Komfortsignaturen erstellen“.
    9.    Die reservierte Ressource Signaturkarte wird wieder freigegeben. Zur Freigabe der Signaturkarte wird TUC_KON_023 „Karte reservieren“ 
       cardSession;
       doLock = false }
    aufgerufen.
    10.    Die signierten Dokumente werden an den Aufrufer zurückgegeben.
    Varianten/
    Alternativen
    keine
    Fehlerfälle



    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes.
    In den Fehlerfällen, die zum Abbruch des Komfortsignaturmodus mit Fehlercode 4271 führen, wird vor dem Abbruch TUC_KON_172 für das cardHandle des HBA ausgeführt.

    (->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263
    (->2) Der Komfortsignatur-Timer der cardSession ist abgelaufen: Fehlercode 4271
    (->3) Ungültige Angabe des Signaturtyps oder Signaturvariante:

             Fehlercode 4111
             Übergabe eines für die QES nicht unterstützten Dokumentformats:
             Fehlercode 4110
    (->4) Kartentyp nicht zulässig für Signatur: Fehlercode 4126
    (->6) Fehler bei der Reservierung der Signaturkarte: Fehlercode 4060
    (->8) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4274

    Im Fehlerfall:
     a)      … DARF DF.QES NICHT verlassen werden
     b)      … MÜSSEN alle reservierten Ressourcen freigegeben werden
     c)      … MUSS der Fehler immer an das Clientsystem zurückgemeldet
        werden
    Sicherheits-anforderungen
    Der Konnektor MUSS sicherstellen, dass der erhöhte Sicherheitszustand der PIN.QES nur für die Komfortsignatur mittels TUC_KON_170 innerhalb einer Kartensitzung nachgenutzt werden darf.

    Tabelle 224: TAB_KON_872 Fehlercodes TUC_KON_170 „Dokumente mit Komfort signieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4060
    Technical
    Error
    Ressource belegt
    4110
    Technical
    Error
    ungültiges Dokumentformat (%Format%)
    Der Parameter Format enthält das übergebene Dokumentformat.
    4111
    Technical
    Error
    ungültiger Signaturtyp oder Signaturvariante
    4126
    Security
    Error
    Kartentyp nicht zulässig für Signatur
    4049
    Technical
    Error
    Abbruch durch den Benutzer
    4263
    Technical
    Error
    Komfortsignaturfunktion nicht aktiviert
    4271 Technical Error Komfortsignaturmodus abgebrochen
    4274 Technical Error Komfortsignaturen werden nur für den HBA unterstützt
    <=

    4.1.8.4.8 TUC_KON_171 „Komfortsignatur einschalten”

    A_19104-04

    Der Konnektor MUSS den technischen Use Case TUC_KON_171 „Komfortsignatur einschalten“ umsetzen.

    Tabelle 225: TAB_KON_883 – TUC_KON_171 „Komfortsignatur einschalten“

    Element
    Beschreibung
    Name
    TUC_KON_171 „Komfortsignatur einschalten“
    Beschreibung


    Zum Einschalten des Komfortsignaturmodus wird die PIN.QES verifiziert und der Signaturmodus „Comfort“ für die cardSession gesetzt.
    Auslöser


    ·         Operation ActivateComfortSignature
    ·         Aufruf durch ein Fachmodul
    Vorbedingungen
    Der Karte muss gesteckt sein.
    Eingangsdaten
    ·         cardSession (nur HBA erlaubt)
    Komponenten
    Konnektor, Kartenterminal, Karte (HBA)
    Ausgangsdaten
    ·         signatureMode
    Standardablauf


    1.    Prüfe SAK_COMFORT_SIGNATURE = Enabled
    2.    Die am Vorgang beteiligten Ressourcen (Karte sowie PIN-Pad und Display des PIN-Eingabe-Kartenterminals) werden für die exklusive Nutzung durch diesen Vorgang reserviert. Die Reservierung der Karte erfolgt durch Aufruf von
    TUC_KON_023 „Karte reservieren“ {
        cardSession;
        doLock = true }
    Der Zugriff auf die Karte im Schritt 3 muss im DF.QES erfolgen. Das DF.QES darf danach nicht verlassen werden, damit der PIN-Status der PIN.QES erhalten bleibt.
    3.    Die Einschaltung der Komfortsignatur wird durch den Anwender autorisiert. Dies erfolgt durch Aufruf von TUC_KON_012 „PIN verifizieren“ { cardSession;
    workplaceId;
    pinRef = PIN.QES;
    verificationType = Mandatorisch }
    Für die Anzeige am Kartenterminal ist die Displaymessage für „Komfortsignatur aktivieren“ aus TAB_KON_090 zu verwenden.
    4.    Setze CARDSESSION.SIGNMODE = Comfort
    5.    Starte Komfortsignatur-Timer für die cardSession bei „0“
    6.    Die reservierten Ressourcen (Karte sowie PIN-Pad und
    Display des PIN-Eingabe-Kartenterminals) werden wieder freigegeben.
    Zur Freigabe der Karte wird TUC_KON_023 „Karte reservieren“ 
       cardSession;
       doLock = false }
    aufgerufen.
    Varianten/
    Alternativen

    Keine
    Fehlerfälle


    Fehler in den folgenden Schritten des Standardablaufs führen zum Abbruch mit den ausgewiesenen Fehlercodes:
    (->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263
    (->) Keine Komfortsignatursession für den HBA aktivierbar, da Maximalzahl an parallelen Komfortsignatursessions erschöpft:
    Fehlercode 4278
    (->2) Fehler bei der Reservierung von Ressourcen: Fehlercode 4060
    (->3) Karte ist kein HBA, sondern HBA-Vorläuferkarte: Fehlercode 4274

    (->3) pinResult = BLOCKED: Fehlercode 4275
    (->3) pinResult = REJECTED: Fehlercode 4276
    (->4) Fehler beim Setzen des Signaturmodus: Fehlercode 4267

    (->5) Fehler beim Starten des Komfortsignatur-Timers: Fehlercode 4267
    Im Fehlerfall, inklusive Timeout bei der PIN-Eingabe, oder bei Abbruch durch den Benutzer (Fehler 4049):
     a)     … MUSS (ab Schritt 5) CARDSESSION.SIGNMODE = PIN gesetzt werden
     b)      … MUSS (ab Schritt 3) DF.QES verlassen werden
     c)      … MÜSSEN alle reservierten Ressourcen freigegeben werden
     d)      … MUSS der Fehler immer an das Clientsystem zurückgemeldet werden


    Tabelle 226: TAB_KON_886 Fehlercodes TUC_KON_171 „Komfortsignatur einschalten“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4049
    Technical
    Error
    Abbruch durch den Benutzer
    4060
    Technical
    Error
    Ressource belegt
    4263
    Technical
    Error
    Komfortsignaturfunktion nicht aktiviert
    4267
    Technical
    Error
    Fehler beim Aktivieren des Komfortsignaturmodus <cardHandle>
    4274 Technical Error Komfortsignaturen werden nur für den HBA unterstützt
    4275 Technical Error Security Error PIN jetzt gesperrt (BLOCKED)
    4276 Technical Error Security Error PIN falsch (REJECTED)
    4278 Technical Error Keine Komfortsignatursession mehr verfügbar
    <=

    4.1.8.4.9 TUC_KON_172 „Komfortsignatur ausschalten”

    A_19105

    Der Konnektor MUSS den technischen Use Case TUC_KON_172 „Komfortsignatur ausschalten“ umsetzen.

    Tabelle 227: TAB_KON_884 – TUC_KON_172 „Komfortsignatur ausschalten“

    Element
    Beschreibung
    Name
    TUC_KON_172 „Komfortsignatur ausschalten“
    Beschreibung


    Zum Ausschalten des Komfortsignaturmodus werden die Sicherheitszustände der Karte(n), die im Konnektor verwalteten Sicherheitszustände und der Signaturmodus der cardSession(s) zurückgesetzt.
    Auslöser


    ·         Operation DeactivateComfortSignature
    ·         TUC_KON_158
    ·         Der Administrator setzt SAK_COMFORT_SIGNATURE = Disabled
    ·         Aufruf durch ein Fachmodul
    Vorbedingungen
    Die Karten müssen gesteckt sein.
    Eingangsdaten


    Bei Auslösen des TUCs durch den Administrator:
    ·         Keine
    Ansonsten:
    ·         cardHandles : Liste von cardHandles (nur HBA erlaubt)
    Komponenten
    Konnektor, Kartenterminal, Karte (HBA)
    Ausgangsdaten
    Keine
    Standardablauf


    1.    Wenn der TUC nicht durch den Administrator ausgelöst wurde:
    Prüfe
    SAK_COMFORT_SIGNATURE = Enabled
    2.    Wenn der TUC durch den Administrator ausgelöst wurde: Ermittle die cardHandles aller gesteckten HBA.
    3.    Für jedes übergebene bzw. ermittelte cardHandle:
    4.    Ermittle cardSessions zu cardHandle
    5.    Für jede ermittelte cardSession:
    a.    Setze den PIN-Status der PIN.QES zurück (z. B. durch Verlassen von DF.QES für alle logischen Kanäle der Karte)
    b.    Lösche den im Konnektor verwalteten Sicherheitszustand aus CARDSESSION.AUTHSTATE (PINRef=PIN.QES)
    c.    Setze CARDSESSION.SIGNMODE = PIN
    d.    Stoppe Komfortsignatur-Timer für die cardSession
    Varianten/
    Alternativen

    Keine
    Fehlerfälle


     
    (->1) Komfortsignaturfunktion im Konnektor nicht aktiviert: Fehlercode 4263
    Fehler und Warnungen in den folgenden Schritten werden über alle cardHandle akkumuliert und die <komma-separierte Liste von cardHandle> für den jeweiligen Fehlertext erzeugt.
    (->3) Bei einem ungültigen cardHandle wird mit dem nächsten cardHandle aus cardHandles fortgesetzt. Fehlercode 4265
    (->4) Ist zu einem cardHandle keine cardSession vorhanden wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4266
    (->5) Tritt in Schritt 4 ein Fehler auf wird mit dem nächsten cardHandle fortgesetzt. Fehlercode 4268
     

    Tabelle 228: TAB_KON_887 Fehlercodes TUC_KON_172 „Komfortsignatur ausschalten“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4263
    Technical
    Fehler
    Komfortsignaturfunktion nicht aktiviert
    4265
    Technical
    Warning
    Karten-Handle ungültig <komma-separierte Liste von cardHandle>
    4266
    Technical
    Warning
    Keine Kartensitzung vorhanden <komma-separierte Liste von cardHandle>
    4268
    Technical
    Fehler
    Fehler beim Deaktivieren des Komfortsignaturmodus <komma-separierte Liste von cardHandle>
    <=

    4.1.8.4.10 TUC_KON_173 „Liefere Signaturmodus”

    A_19106-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_173 „Liefere Signaturmodus“ umsetzen.

    Tabelle 229: TAB_KON_885 – TUC_KON_173 „Liefere Signaturmodus“

    Element
    Beschreibung
    Name
    TUC_KON_173 „Liefere Signaturmodus“
    Beschreibung


    Der aktuell konfigurierte Status der Komfortsignaturfunktion im Konnektor und Informationen zur Komfortsignatursession werden ermittelt und an den Aufrufer zurückgegeben.
    Auslöser


    ·         Operation GetSignatureMode
    ·         Aufruf durch ein Fachmodul
    Vorbedingungen
    Keine
    Eingangsdaten
    ·     cardSession 
    (Kartensitzung. Unterstützte Kartentypen: HBA)
    Komponenten
    Konnektor, Kartenterminal, Signaturkarte (HBA)
    Ausgangsdaten


    ·         comfortSignatureStatus
    ·         comfortSignatureMax
    ·         comfortSignatureTimer
    ·         sessionInfo (optional): Struktur aus
    signatureMode, countRemaining, timeRemaining
    Standardablauf


    1. Ermittle den Status der Komfortsignaturfunktion: comfortSignatureStatus=SAK_COMFORT_SIGNATURE
    2. Ermittle comfortSignatureMax= SAK_COMFORT_SIGNATURE_MAX
    3. Ermittle comfortSignatureTimer= SAK_COMFORT_SIGNATURE_Timer
    4. Ermittle sessionInfo
      1. Ermittle den Signaturmodus (signatureMode) aus CARDSESSION.SIGNMODE
      2. Ermittle Differenz von SAK_COMFORT_SIGNATURE_MAX und Komfortsignatur-Zähler der cardSession (countRemaining)

      3. Ermittle verbleibende Zeit aus SAK_COMFORT_SIGNATURE_TIMER und Komfortsignatur-Timer der cardSession (timeRemaining)

    5. Wenn signatureMode = "Comfort" wird sessionInfo an den Aufrufer zurückgegeben.
    Varianten/
    Alternativen
    (->4b) Der Rückgabewert für countRemaining muss für jede Komfortsignatursession den aktuellen Stand zur Anzahl verbleibender Komfortsignaturen wiedergeben unter Einbezug
    a)   ggf. parallel existierender Sessions auf ein und demselben logischen Kanal des HBA,
    b)   der maximal durch die Karte in diesem logischen Kanal erlaubten Komfortsignaturen (laut [gemSpec_HBA_ObjSys*] 250) und
    c)   der konfigurierten maximal erlaubten Anzahl an Komfortsignaturen für die betreffende Session (SAK_COMFORT_SIGNATURE_MAX).
    Fehlerfälle
    Wenn im Standardablauf ein Fehler auftritt, wird mit Fehler 4269 abgebrochen.
     

    Tabelle 230: TAB_KON_888 Fehlercodes TUC_KON_173 „Liefere Signaturmodus“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4269
    Technical
    Error
    Fehler beim Ermitteln des Signaturmodus <cardHandle>
    <=

    4.1.8.5 Operationen an der Außenschnittstelle

    TIP1-A_4676-08

    Der Konnektor MUSS Clientsystemen den Basisdienst Signaturdienst (nonQES und QES) anbieten.

    Tabelle 231: TAB_KON_197 Basisdienst Signaturdienst (nonQES und QES)

    Name
    SignatureService
    Version (KDV)
    7.4.0 (WSDL-Version), 7.4.2 (XSD-Version)
    7.4.2 (WSDL-Version), 7.4.4 (XSD-Version)
    7.5.5 (WSDL- und XSD-Version)
    Siehe Anhang D
    Namensraum
    Siehe Anhang D
    Namensraum-Kürzel
    SIG für Schema und SIGW für WSDL
    Operationen
    Name
    Kurzbeschreibung
    SignDocument
    Dokument signieren
    VerifyDocument
    Signatur verifizieren
    StopSignature
    Signieren eines Dokumentenstapels abbrechen
    GetJobNumber
    Liefert eine Jobnummer für den nächsten Signiervorgang
    ActivateComfortSignature Aktiviert die Komfortsignatur für einen HBA
    DeactivateComfortSignature Deaktiviert die Komfortsignatur für einen oder mehrere HBA
    GetSignatureMode Liefert den Status der Komfortsignaturfunktion und Informationen zur Komfortsignatursession eines HBA
    WSDL
    SignatureService_V7_5_5.wsdl
    SignatureService_V7_4_2.wsdl
    SignatureService.wsdl (WSDL-Version 7.4.0)

    Schema
    SignatureService_V7_5_5.xsd
    SignatureService_V7_4_4.xsd
    SignatureService.xsd (XSD-Version 7.4.2)
    <=

    4.1.8.5.1 SignDocument (nonQES und QES)

    TIP1-A_5010-09

    Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine an [OASIS-DSS] angelehnte Operation SignDocument anbieten.

    Tabelle 232: TAB_KON_065 Operation SignDocument (nonQES und QES)

    Name
    SignDocument
    Beschreibung
    Diese Operation lehnt sich an [OASIS-DSS] an. Sie enthält voneinander unabhängige SignRequests. Jeder SignRequest erzeugt eine Signatur für ein Dokument.
    Für die qualifizierte elektronische Signatur (QES) werden die QES_DocFormate unterstützt. Für nicht-qualifizierte elektronische Signaturen (nonQES) werden die nonQES_DocFormate unterstützt.
    Zur Signaturerzeugung werden Schlüssel und Zertifikate einer Chipkarte benutzt.
    Unterstützte Karten sind für die QES der HBAx mit dem QES-Zertifikat. Für die nonQES wird für die Signaturtypen „XML-Signatur, CMS-Signatur, PDF-Signatur, S/MIME-Signatur“ die SM-B mit dem OSIG–Zertifikat unterstützt.
    Bei der Erstellung von XML-Signaturen MUSS Canonical XML 1.1 verwendet werden [CanonXML1.1].
    Es soll der Common-PKI-Standard eingesetzt werden, siehe [Common-PKI].
    In Summe für die Größe der Dokumente in allen SignRequests innerhalb einer SignDocument-Anfrage MUSS der Konnektor eine Gesamtgröße von <= 250 MB unterstützen.
    Aufruf-parameter


    Name
    Beschreibung
    CONN:
    Card
    Handle

    Identifiziert die zu verwendende Signaturkarte.
    Die Operation DARF die Signatur mit der eGK NICHT unterstützen. Wird die Operation mit einem nicht unterstützten Kartentypen aufgerufen, so MUSS der Konnektor die Bearbeitung mit dem Fehler 4126 abbrechen.
    SIG:
    Crypt
    Der Parameter crypt steuert die Auswahl der Zertifikate und Schlüssel für die Signaturerstellung abhängig von der durch cardHandle adressierten Karte gemäß TAB_KON_900.
    Defaultwert: 

    • gemäß TAB_KON_862-01 für die QES 
    • gemäß TAB_KON_863 für die nonQES.
    CCTX:
    Context

    Aufrufkontext QES mit HBAx:
    MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend
    Aufrufkontext nonQES mit SM-B:
    MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet
    TvMode
    Der Parameter wird im Konnektor nicht ausgewertet.
    SIG:
    JobNumber

    Die Nummer des Jobs, unter der der nächste Signaturvorgang gestartet wird.
    Parameter ist verpflichtend.
    SIG:
    Sign
    Request

    Ein SignRequest kapselt den Signaturauftrag für ein Dokument.
    Das verpflichtende XML-Attribut RequestID identifiziert einen SignRequest innerhalb eines Stapels von SignRequests eindeutig. Es dient der Zuordnung der SignResponse zum jeweiligen SignRequest.
    Enthält der Aufruf mehr als die unterstützte Anzahl von SignRequests, bricht die Operation mit Fehler 4000 ab.
    Es sind mindestens 50 SignRequests zu unterstützen.
    SIG:
    Optional
    Inputs

    Enthält optionale Eingangsparameter (angelehnt an dss:OptionalInputs gemäß [OASIS-DSS] Section 2.7):


    SIG:
    Document




    Dieses an das dss:Document Element aus [OASIS-DSS] Section 2.4.2 angelehnte Element enthält das zu signierende Dokument, wobei die Kindelemente CONN:Base64XML und dss:Base64Data auftreten können.
    Bei den als dss:Base64Data übergebenen Dokumenten werden folgende (Klassen von) MIME-Types unterschieden:
    • ”application/pdf-a” – für PDF/A-Dokumente,
    • ”text/plain”,
      ”text/plain; charset=iso-8859-15” oder
      ”text/plain; charset=utf-8” – für Text-Dokumente,
    • ”image/tiff” – für TIFF-Dokumente und
    • ein beliebiger anderer MIME-Type für nicht näher unterschiedene Binärdaten des spezifizierten Typs.
    Der MIME-Type „text/plain“ wird interpretiert als „text/plain; charset=iso-8859-15”.
    Das Element enthält ein Attribut ShortText Es muss für QES-Signaturen bei jedem Aufruf vom Clientsystem übergeben werden, für nonQES-Signaturen ist es optional.
    Über das Attribut RefURI kann gemäß [OASIS-DSS] (Abschnitt 2.4.1) ein zu signierender Teilbaum eines XML-Dokuments ausgewählt werden. 
    Wenn die Signatur eines Teilbaums für die 
    Signaturvariante nicht unterstützt wird, muss der Signaturauftrag mit Fehler 4111 abgelehnt werden.
    SIG:
    Include
    Revocation
    Info

    Durch diesen verpflichtenden Schalter kann der Aufrufer die Einbettung von zum Zeitpunkt der Signaturerstellung vorliegenden Sperrinformationen anfordern. Es wird ausschließlich die zu erstellende Signatur betrachtet, d.h. es erfolgt keine Einbettung von Sperrinformationen für bereits enthaltene Signaturen.
    Für nicht-qualifizierte elektronische Signaturen (nonQES) wird diese Funktionalität nicht unterstützt.
     Für PDF-Signaturen werden keine Sperrinformationen eingebettet.
    dss:
    Signature
    Type

    Durch dieses in [OASIS-DSS] (Abschnitt 3.5.1) beschriebene Element kann der generelle Typ der zu erzeugenden Signaturen spezifiziert werden. Hierbei MÜSSEN folgende Signaturtypen unterstützt werden:
    • XML-Signatur
      Durch Übergabe der URI urn:ietf:rfc:3275 wird die Erstellung von XML-Signaturen gemäß [RFC3275], [XMLDSig] angestoßen.
      Das zu verwendende Profil ist XAdES-BES ([XAdES]). Die Rückgabe einer solchen Signatur erfolgt als ds:Signature-Element.
    • CMS-Signatur
      Durch Übergabe der URI urn:ietf:rfc:5652 wird eine CMS-Signatur gemäß [RFC5652] angestoßen. Das zu verwendende Profil ist CAdES-BES ([CAdES]). 
      Die Signatur wird als dss:Base64Signature mit der oben genannten URI als Type zurückgeliefert.
    • PDF-Signatur
      Durch Übergabe der URI http://uri.etsi.org/02778/3 wird die Erzeugung einer PAdES-Basic Signatur gemäß [PAdES-3]angestoßen, wobei das Dokument mit der integrierten Signatur als dss:Base64Signature mit der oben genannten URI als Type zurückgeliefert wird.
      Handelt es sich beim übergebenen Dokument nicht um ein Base64Data-Element mit MIME-Type „application/pdf-a“, so wird ein Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert.
    Die nachfolgenden Werte KÖNNEN unterstützt werden:
    • S/MIME-Signatur
      Durch Übergabe der URI „urn:ietf:rfc:5751” wird eine S/MIME-Signatur gemäß [RFC5751] angestoßen.
      Die CMS-Signatur der übergebenen MIME-Nachricht erfolgt konform der Vorgaben zur CMS-Signatur. Das Rückgabedokument ist eine MIME-Nachricht vom Typ „application/pkcs7-mime“ mit einer CMS-Struktur vom Typ_SignedData.
      Ist das übergebene Dokument keine MIME-Nachricht, so wie der Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert.
    Der Konnektor KANN die Operation im Fall S/MIME mit Fehlercode 4279 beenden. 

    Andere SignatureType-Angaben führen zu einer Fehlermeldung 4111 (Ungültiger Signaturtyp oder Signaturvariante).
    Die Signaturtypen „XML-Signatur, CMS-Signatur, PDF-Signatur, S/MIME-Signatur“ DÜRFEN für QES der HBAx nur mit dem QES-Zertifikat erfolgen, für nonQES nur mit dem OSIG-Zertifikat der SM-B. In jedem diese Anforderung verletzenden Fall MUSS der Fehler 4058 (Aufruf nicht zulässig) zurückgeliefert werden.
    Fehlt dieses Element, so wird der Signaturtyp gemäß TAB_KON_583 – Default-Signaturverfahren aus dem Dokumententyp abgeleitet.
    dss:
    Properties

    Durch dieses in [OASIS-DSS] (Abschnitt 3.5.5) definierte Element können zusätzliche signierte und unsignierte Eigenschaften (Properties) bzw. Attribute in die Signatur eingefügt werden.
    Unterstützt werden genau folgende Attribute:
    Im CMS-Fall (SignatureType = urn:ietf:rfc:5652) kann es XML-Elemente
    ./SignedProperties/Property/Value/CMSAttribute
    und
    ./UnsignedProperties/Property/Value
    /CMSAttribute

    enthalten. Ein solches XML-Element CMSAttribute muss ein vollständiges, base64/DER-kodiertes ASN.1-Attribute enthalten, definiert in [CMS#5.3.SignerInfo Type]. Es muss bei der Erstellung des CMS-Containers unverändert unter SignedAttributes bzw. UnsignedAttributes aufgenommen werden.
    Die Übergabe der Attribute
    • ContentType
    • SigningTime
    • MessageDigest
    • SigningCertificate und SigningCertificateV2
    wird ignoriert und es wird die Warnung 4273 zurück gegeben.
    SIG:
    Include
    EContent

    Durch dieses in [OASIS-DSS] (Abschnitt 3.5.7), definierte Element kann bei einer CMS-basierten Signatur das Einfügen des signierten Dokumentes in die Signatur angefordert werden.
    Die Verwendung dieses Parameters bei anderen Signaturtypen führt zu einem Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante).
    SIG:
    Include
    Object

    Dieses Element enthält zum Anfordern einer Enveloping XML Signatur ein dss:IncludeObject-Element gemäß [OASIS-DSS] (Abschnitt 3.5.6).
    Ist das Element vorhanden und ein anderer Signaturtyp als eine XML-Signatur angefordert, so wird der Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert.
    dss:
    Signature
    Placement

    Durch dieses in [OASIS-DSS] (Abschnitt 3.5.8) definierte Element kann bei XML-basierten Signaturen gemäß [RFC3275] die Platzierung der Signatur im Dokument angegeben werden.
    Die in [OASIS-DSS] (Abschnitt 2.5, XPath c) beschriebene Deklaration von Namespace-Prefixes im dss:SignaturePlacement-Element muss nicht unterstützt werden. 
    Bei anderen Signaturtypen wird das Element ignoriert und eine Warnung (Fehlercode 4197, Parameter SignaturePlacement wurde ignoriert) zurückgeliefert.
    dss:SignaturePlacement darf nur zusammen mit einer unterstützten Signaturrichtlinie verwendet werden (sp:SignaturePolicyIdentifier muss entsprechend gesetzt sein).
    dss:
    Return
    Updated
    Signature

    Durch dieses in [OASIS-DSS] (Abschnitt 4.5.8) definierte Element kann eine übergegebene XML- oder CMS-Signatur mit zusätzlichen Informationen und Signaturen (Parallel- und Gegensignaturen) versehen werden. Hierbei sind folgende Ausprägungen für das Type-Attribut vorgesehen:
    • http://ws.gematik.de/conn/sig/sigupdate/parallel
      Hierdurch wird eine Parallelsignatur zu einer bereits existierenden Signatur erzeugt und entsprechend zurückgeliefert.
    • http://ws.gematik.de/conn/sig/sigupdate/counter/
      documentexcluding

      Hierdurch wird eine dokumentenexkludierende Gegensignatur für alle vorhandenen parallelen Signaturen erzeugt.
    Bei anderen Type-Attributen wird der Fehler 4111 (Ungültiger Signaturtyp oder Signaturvariante) zurückgeliefert.
    dss:
    Schemas

    Durch das in [OASIS-DSS] (Abschnitt 2.8.5) definierte Element können eine Menge von XML-Schemata übergeben werden, die zur Validierung der übergebenen XML-Dokumente verwendet werden können.

    dss:Schema
    Dieses Element enthält ein XML-Schema zur Validierung des übergebenen XML-Dokuments. Das Attribut RefURI ist verpflichtend. Es kennzeichnet dabei den Namensraum des XML-Schemas entsprechend [OASIS-DSS] (Abschnitt 2.8.5)
    sp:
    Generate
    Under
    Signature
    Policy




    Über dieses in [OASIS-SP], Kapitel 2.2.1.1.1.1 Optional Input <GenerateUnderSignaturePolicy>, definierte Element wird die  erforderliche Singnaturrichlinie ausgewählt.
    Die im Element sp:SignaturePolicyIdentifier übergebene URI identifiziert die Signaturrichtlinie.
    Die XML-Elemente
    SignaturePolicyLocation
    DigestAndAlgorithm

    werden nicht verwendet.
    Wenn eine nach TAB_KON_778 notwendige Signaturrichtlinie fehlt oder die übergebene Signaturrichtlinie unbekannt ist, wird Fehler 4111 zurückgeliefert.  
    SIG:
    Viewer
    Info

    Enthält optional die vom Konnektor in die Signatur einzubeziehende Referenzen für die Stylesheets zur Anzeige.
    Rückgabe



    SIG:SignResponse
    Eine SignResponse kapselt den ausgeführten Signaturauftrag pro Dokument. Die Zuordnung zwischen SignRequest und SignResponse erfolgt über die RequestID.
    CONN:Status Enthält den Status der ausgeführten Operation pro SignRequest.
    SIG:
    Optional
    Outputs

    Enthält (angelehnt an dss:OptionalOutputs) optionale Ausgangsparameter:

    SIG:
    Document
    With
    Signature




    Pro SignResponse wird ein Element SIG:DocumentWithSignature gemäß [OASIS-DSS] (Abschnitt 3.5.8) zurückgeliefert, in dem das Dokument mit Signatur enthalten ist. Dabei werden die XML-Attribute des Elements SIG:Document auf dem zugehörigen SignRequest übernommen.
    Ist die Signatur nicht im Dokument enthalten, wird ein leeres Element Base64XML oder Base64Data zurückgegeben. Die Signatur wird dann im Element dss:SignatureObject abgelegt.
    Wenn die Signatur im Dokument enthalten ist, wird das signierte Dokument im Feld Base64XML bzw. Base64Data zurückgeliefert. In diesem Fall MUSS die dss:SignaturePtr-Alternative in dss:SignatureObject (vgl. [OASIS-DSS] Abschnitt 2.5) dazu genutzt werden, auf die in den Dokumenten enthaltenen Signaturen zu verweisen.
    vr:
    VerificationReport

    Vom Konnektor nicht befüllt.
    dss:
    SignatureObject

    Enthält im Erfolgsfall die erzeugte Signatur pro SignRequest in Form eines dss:SignatureObject-Elementes gemäß [OASIS-DSS] (Abschnitt 3.2).
    Vorbe-dingungen Keine
    Nachbe-dingungen Keine
    Der Ablauf der Operation SignDocument ist in Tabelle TAB_KON_756 Ablauf Operation SignDocument (nonQES und QES) beschrieben:

    Tabelle 233: TAB_KON_756 Ablauf Operation SignDocument (nonQES und QES)

    Nr.
    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung
    1.

    checkArguments
    Anhand des Kartentyps wird ermittelt, ob eine QES oder eine nonQES erzeugt werden soll. Alle übergebenen Parameterwerte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.

    TUC_KON_000 „Prüfe Zugriffs- berechtigung“
    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle = $cardHandle }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3.

    TUC_KON_026 „Liefere CardSession“
    Ermittle CardSession über TUC_KON_026 {
        mandatId =$context.mandantId;
        clientsystemId  = $context.clientsystemId;
        cardHandle = $context.cardHandle;
        userId = $context.userId }
    Im Fall QES wird Schritt 4 ausgeführt. Im Fall nonQES wird Schritt 5 ausgeführt.
    4a)
    Prüfe Signaturdienst-Modul
    Prüfe, ob MGM_LU_SAK=Enabled. Ist dies nicht der Fall, so bricht die Operation mit Fehler 4125 ab.
    Wenn für die CardSession die Komfortsignatur aktiviert ist (CARDSESSION.SIGNMODE = Comfort) wird Schritt 4 c) ausgeführt. Andernfalls wird Schritt 4 b) ausgeführt.
    4b)
    TUC_KON_150 „Dokumente QES signieren“
    Die QES wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab.
    4c) TUC_KON_170 „Dokumente mit Komfort signieren“ Eine Komfortsignatur wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab.
    5)
    TUC_KON_160 „Dokumente nonQES signieren“
    Die nonQES wird erzeugt. Tritt hierbei ein Fehler auf, bricht die Operation ab.

    Tabelle 234: TAB_KON_757 Fehlercodes „SignDocument (nonQES und QES)“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4111 Technical Error ungültiger Signaturtyp oder Signaturvariante
    4126
    Security
    Error
    Kartentyp nicht zulässig für Signatur
    4125
    Technical
    Error
    LU_SAK nicht aktiviert
    4197
    Technical
    Warning
    Parameter SignaturePlacement wurde ignoriert
    4252 Technical Error
    Jobnummer wurde in den letzten 1.000 Aufrufen bereits verwendet und ist nicht zulässig
    4273 Technical  Warning Attribute im Parameter dss:Properties wurden ignoriert
    4279 Technical  Error S/MIME-Funktionalität nicht unterstützt
    4283 Technical Error Dokument zu groß

    Die zulässigen Zertifikate und Schlüssel sind in TAB_KON_900 aufgelistet.
    <=

    4.1.8.5.2 VerifyDocument (nonQES und QES)

    TIP1-A_5034-06

    Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine an [OASIS-DSS] angelehnte Operation VerifyDocument (nonQES und QES) anbieten.

    Tabelle 235: TAB_KON_066 Operation VerifyDocument (nonQES und QES)

    Name
    VerifyDocument
    Beschreibung
    Diese Operation verifiziert die Signatur eines Dokumentes.
    Der Konnektor MUSS jede konform zur Außenschnittstelle SignDocument erzeugte Signatur durch VerifyDocument prüfen können.
    Das Ergebnis der Prüfung wird, wenn gefordert, in Form eines standardisierten Prüfberichts in einer VerificationReport-Struktur gemäß [OASIS-VR] zurückgeliefert.
    Aufruf-parameter



                
    Name
    Beschreibung
    CCTX:
    Context
    MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet
    TvMode
    Der Parameter wird im Konnektor nicht ausgewertet.
    SIG:
    Optional
    Inputs
    Enthält optionale Eingabeparameter (angelehnt an dss:OptionalInputs gemäß [OASIS-DSS] Section 2.7):
    Die zulässigen optionalen Eingabeparameter sind unten erläutert.
    SIG:
    Document
    Enthält im Fall der Prüfung von detached oder enveloped Signaturen das zur Signatur gehörende bzw. das diese umschließende Dokument (siehe [OASIS-DSS] Section 2.4.2 und oben).
    dss:
    Signa
    ture
    Object
    Enthält die zu prüfende Signatur, wenn sie nicht im Dokument selbst eingebettet ist ([OASIS-DSS] Kapitel 4.1). Hierbei werden XML-Signaturen als ds:Signature Element und alle anderen Signaturen als dss:Base64Signature mit entsprechend gesetztem Type-Attribut (siehe SignatureType, Operation SignDocument) übergeben, wobei die nachfolgenden Werte unterstützt werden MÜSSEN:
    Die nachfolgenden Werte KÖNNEN unterstützt werden:
    SIG:
    Include
    Revocat
    ionInfo
    Durch diesen verpflichtenden Schalter kann der Aufrufer die Einbettung von zum Zeitpunkt der Signaturprüfung vorliegenden Sperrinformationen anfordern.
    Ist bereits eine Sperrinformation eingebettet, so wird die neue Sperrinformation zusätzlich eingebettet.
    Für in einer Gegensignatur enthaltene Signaturen erfolgt keine Einbettung von Sperrinformationen. Für PDF-Signaturen erfolgt keine Einbettung von Sperrinformationen. Der Konnektor nimmt die Warnung 4261 in die Antwort auf. 



    SIG:
    Verify
    Mani
    fests
    Durch das in [OASIS-DSS] (Abschnitt 4.5.1) definierte Element kann die Prüfung eines ggf. vorhandenen Manifests angefordert werden.


    SIG:
    Use
    Verifi
    cation
    Time
    Durch das in [OASIS-DSS] (Abschnitt 4.5.2) spezifizierte Element kann die Prüfung der Signatur bezüglich eines durch den Aufrufer bestimmten Zeitpunktes (Benutzerdefinierter_Zeitpunkt) erfolgen.
    dss:
    Addit
    ional
    KeyInfo
    Durch das in [OASIS-DSS] (Abschnitt 4.5.4) spezifizierte Element kann zusätzliches, für die Prüfung benötigtes, Schlüsselmaterial übergeben werden.
    vr:
    Return
    Verifi
    cation
    Report
    Durch dieses in [OASIS-VR] spezifizierte Element kann die Erstellung eines ausführlichen Prüfberichtes angefordert werden. Der Konnektor MUSS die Anforderungen der Konformitätsstufe 2 („Comprehensive“) erfüllen und die Profilierung aus Anhang B3 beachten.
    dss:
    Schemas
    Durch das in [OASIS-DSS] (Abschnitt 2.8.5) definierte Element können eine Menge von XML-Schematas übergeben werden, die zur Validierung des übergebenen XML-Dokumentes verwendet werden können.
    Zur Struktur dieses Elements siehe Beschreibung des Parameters dss:Schemas der Operation SignDocument.
    SIG:
    Viewer
    Info
    Der Parameter wird im Konnektor nicht ausgewertet.
    Rückgabe


    Status
    Enthält den Ausführungsstatus der Operation.
    SIG:
    Verifi
    cation
    Result


    Das Element Sig:VerificationResult enthält das Ergebnis der Prüfung als Ampel, den Typ des zugehörigen angenommenen Signaturzeitpunkts und der angenommene Signaturzeitpunkt selbst.
    SIG:
    High
    Level
    Result
    Das Ergebnis der Prüfung (Ampelschaltung) mit folgenden Werten:
    • VALID: alle Signaturen sind gültig
    • INVALID: mindestens eine der Signaturen ist ungültig
    • INCONCLUSIVE: in allen anderen Fällen
    SIG:
    Time
    stamp
    Type
    Der Typ des angenommenen Signaturzeitpunkts mit folgenden Werten:
    •      SIGNATURE_EMBEDDED_TIMESTAMP:
      in der Signatur eingebetter Zeitpunkt  
      Ermittelter_Signaturzeitpunkt
      _Eingebettet
    •      SYSTEM_TIMESTAMP:
      Systemzeit des Konnektors bei Signaturprüfung
      Ermittelter_Signaturzeitpunkt
      _System
    •      USER_DEFINED_TIMESTAMP:
      benutzerdefinierter Zeitpunkt
      Benutzerdefinierter_Zeitpunkt
    Als Format darf jedes zum XML-Typ "dateTime" konforme Format verwendet werden (<element name="Timestamp" type="dateTime"/>). Wenn mehrere Signaturen im Dokument vorhanden sind, wird hier der angenommene Signaturzeitpunkt der jüngsten Signatur angegeben.
    SIG:
    Time
    stamp
    Im Element SIG:Timestamp wird der zu SIG:TimestampType gehörende Zeitstempel zurückgegeben.
    SIG:
    Optio
    nal
    Outputs
    Enthält (angelehnt an dss:OptionalOutputs, wie in Abschnitt 2.7 von [OASIS-DSS] beschrieben) optionale Ausgangselemente:



    dss:
    Verify
    Manifest
    Results
    Dieses in Abschnitt 4.5.1 von [OASIS-DSS] definierte Element enthält Informationen zur Prüfung eines ggf. vorhandenen Signaturmanifests und wird zurückgeliefert, sofern beim Aufruf das dss:VerifyManifest-Element, aber nicht das RequestVerificationReport als optionales Eingabeelement übergeben wurde.
    SIG:
    Document
    With
    Signa
    ture
    Dieses in Abschnitt 4.5.8 von [OASIS-DSS] spezifizierte Element wird zurückgeliefert, falls eine in dem Dokument enthaltene Signatur (Enveloped Signature) in Verbindung mit dem SIG:IncludeRevocationInfo-Element geprüft wurde.
    dss:
    Updated
    Signa
    ture
    Dieses in Abschnitt 4.5.8 von [OASIS-DSS] spezifizierte Element wird zurückgeliefert, falls eine abgesetzte (Detached Signature) oder umschließende (Enveloping Signature) in Verbindung mit dem SIG:IncludeRevocationInfo- Element geprüft wurde.
    vr:
    Verifi
    cation
    Report
    Dieses in [OASIS-VR] spezifizierte Element wird zurückgeliefert, falls das ReturnVerificationReport-Element als Eingabeparameter verwendet wurde. Die Profilierung von Anhang B3 MUSS beachtet werden.
    Vorbe-dingungen
    Keine
    Nachbe-dingungen
    Keine

    Tabelle 236: TAB_KON_760 Ablauf Operation VerifyDocument (nonQES und QES)

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung


    1.


    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.

    TUC_KON_000 „Prüfe Zugriffs- berechtigung“

    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        needCardSession= false;
    }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.

    3.



    prüfe, ob QES oder nonQES

    Ist im jeweiligen Signaturzertifikat mindestens ein QCStatement mit dem OID id-etsi-qcs-QcCompliance (0.4.0.1862.1.1) enthalten, handelt es sich um eine QES-Signatur, andernfalls liegt eine nonQES-Signatur vor.

    Für QES-Signaturen wird Schritt 4 ausgeführt. Für nonQES-Signaturen wird Schritt 5 ausgeführt.
    Im Fall eines S/MIME-Dokuments KANN der Konnektor die Operation mit Fehlercode 4279 beenden.

    4.a

    Prüfe Signaturdienst-Modul

    Prüfe, ob MGM_LU_SAK=Enabled. Ist dies nicht der Fall, so bricht die Operation mit Fehler 4125 ab.

    4.b

    TUC_KON_151 „QES Dokumentensignatur prüfen“

    Die QES wird geprüft. Tritt hierbei ein Fehler auf, bricht die Operation ab.

    5.

    TUC_KON_161 „nonQES Dokumentensignatur prüfen“

    Die nonQES wird geprüft. Tritt hierbei ein Fehler auf, bricht die Operation ab.


    Tabelle 237: TAB_KON_761 Fehlercodes „VerifyDocument (nonQES und QES)“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen TUCs (siehe Tabelle TAB_KON_760 Ablauf Operation VerifyDocument) können folgende weiteren Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4261 Technical Warning Einbettung von Revocation-Informationen nicht unterstützt
    4125
    Technical
    Error
    LU_SAK nicht aktiviert
    4279 Technical Error S/MIME-Funktionalität nicht unterstützt
    4283 Technical Error Dokument zu groß
    <=

    4.1.8.5.3 StopSignature

    TIP1-A_5666-02

    Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation StopSignature anbieten.


    Tabelle 238: TAB_KON_840 Operation StopSignature

    Name
    StopSignature
    Beschreibung
    Diese Operation unterbricht die Signatur eines Dokumentenstapels.
    Der Konnektor MUSS jede Signaturerstellung für ein Dokumentenstapel unterbrechen können.
    Aufrufparameter

                
    Name
    Beschreibung
    CCTX:Context
    MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet
    SIG: JobNumber
    Die Nummer des Jobs, der gestoppt werden soll.
    Rückgabe


    CONN:Status
    Enthält den Ausführungsstatus der Operation.
    Vorbedingungen
    Keine
    Nachbedingungen
    Keine

    Tabelle 239: TAB_KON_841 Ablauf Operation StopSignature

    Nr.
    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung
    1.

    checkArguments Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Dabei wird auch das CardHandle zu der übergebenen JobNumber ermittelt und dieses CardHandle zusammen mit dem übergebenen Context einer Berechtigungsprüfung unterworfen. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2. Stoppe die Stapelsignaturverarbeitung
    Die Verarbeitung der Stapelsignatur wird abgebrochen


    Tabelle 240: TAB_KON_842 Fehlercodes „StopSignature“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Folgende Fehlercodes können auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4243
    Technical
    Error
    Jobnummer unbekannt
    <=

    4.1.8.5.4 GetJobNumber

    TIP1-A_5667

    Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation GetJobNumber anbieten.

    Tabelle 241: TAB_KON_843 Operation GetJobNumber

    Name
    GetJobNumber
    Beschreibung
    Diese Operation liefert eine Jobnummer zur Verwendung in der Operation SignDocument.
    Die Jobnummer MUSS nach den Vorgaben von Kapitel 4.1.8.1.4 erstellt werden.
    Aufrufparameter



    Name
    Beschreibung
    CCTX:Context
    MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet
    Rückgabe


    SIG: JobNumber
    Jobnummer zur Verwendung in „SignDocument“
    Vorbedingungen
    Keine
    Nachbedingungen
    Keine

    Tabelle 242: TAB_KON_844 Ablauf Operation GetJobNumber

    Nr.
    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung
    1.

    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.

    Generiere und liefere eine Jobnummer
    Eine innerhalb von 1000 Aufrufen eindeutige Jobnummer wird generiert und geliefert. Die Zählung der Aufrufe erfolgt dabei unabhängig vom Aufrufkontext.


    Tabelle 243: TAB_KON_845 Fehlercodes „GetJobNumber“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Folgende Fehlercodes können auftreten:
    4000
    Technical
    Error
    Syntaxfehler

    <=

    4.1.8.5.5 ActivateComfortSignature

    A_19107

    Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation ActivateComfortSignature anbieten.

    Tabelle 244: TAB_KON_874 ActivateComfortSignature

    Name
    ActivateComfortSignature
    Beschreibung
    Diese Operation aktiviert die Komfortsignatur für einen HBA bezogen auf einen Aufrufkontext.
    Aufrufparameter


                 
    Name
    Beschreibung
    CONN:
    Card
    Handle
    Identifiziert die zu adressierende Karte.
    Es wird nur der HBA unterstützt.
    CCTX:Context
    MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend zu übergeben;
    MandantId, WorkplaceId nicht ausgewertet
    Rückgabe

    CONN:Status
    Enthält den Ausführungsstatus der Operation.
    SIG: SignatureMode
    Signaturmodus des HBA
    Enthält bei erfolgreicher Ausführung der Operation den Wert „COMFORT“
    Vorbedingungen
    Keine
    Nachbedingungen
    Keine

    Tabelle 245: TAB_KON_877 Ablauf ActivateComfortSignature

    Nr.


    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung


    1.



    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.
    TUC_KON_000 „Prüfe Zugriffsberechtigung“
    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle = $cardHandle }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3.
    TUC_KON_026 „Liefere CardSession“
    Ermittle CardSession über TUC_KON_026 {
        mandatId =$context.mandantId;
        clientsystemId  = $context.clientsystemId;
        cardHandle = $context.cardHandle;
        userId = $context.userId }
    4.
    TUC_KON_171 „Komfortsignatur einschalten“
    Der Komfortsignaturmodus wird für das Tupel (CardHandle, CardSession) eingeschaltet. Tritt hierbei ein Fehler auf, bricht die Operation ab.
     

    Tabelle 246: TAB_KON_879 Fehlercodes ActivateComfortSignature

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4270
    Technical
    Error
    UserId wurde in den letzten 1.000 Vorgängen bereits verwendet
    4272
    Technical
    Error
    UserId nicht zulässig
    <=

    4.1.8.5.6 DeactivateComfortSignature

    A_19108

    Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation DeactivateComfortSignature anbieten.

    Tabelle 247: TAB_KON_875 DeactivateComfortSignature

    Name
    DeactivateComfortSignature
    Beschreibung
    Diese Operation deaktiviert die Komfortsignatur für einen oder mehrere HBA.
    Aufrufparameter


                
    Name
    Beschreibung
    CONN:
    Card
    Handle


    Identifiziert die zu adressierende Karte.
    Es wird nur der HBA unterstützt.
    Rückgabe



    CONN:Status
    Enthält den Ausführungsstatus der Operation.
    Vorbedingungen
    Keine
    Nachbedingungen
    Keine

    Tabelle 248: TAB_KON_878 Ablauf DeactivateComfortSignature

    Nr.


    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung


    1.



    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.
    TUC_KON_172 „Komfortsignatur ausschalten“
    Der Komfortsignaturmodus wird für alle Karten aus der CardHandle-Liste ausgeschaltet.
     

    Tabelle 249: TAB_KON_880 Fehlercodes DeactivateComfortSignature

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen TUCs können folgende weiteren Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    <=

    4.1.8.5.7 GetSignatureMode

    A_19109-02

    Der Signaturdienst des Konnektors MUSS an der Clientschnittstelle eine Operation GetSignatureMode anbieten.

    Tabelle 250: TAB_KON_876 GetSignatureMode

    Name
    GetSignatureMode
    Beschreibung
    Diese Operation liefert den aktuell konfigurierten Status der Komfortsignaturfunktion im Konnektor und Session-Informationen
    zur Kartensitzung für das CardHandle und den Aufrufkontext, falls sich die Kartensitzung im Komfortsignaturmodus befindet.
    Aufrufparameter


               
    Name
    Beschreibung
    CONN:CardHandle
    Identifiziert die zu adressierende Karte.
    Es wird nur der HBA unterstützt.
    CCTX:Context MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend zu übergeben
    Rückgabe

    CONN:Status Enthält den Ausführungsstatus der Operation.
     
    SIG:
    ComfortSignatureStatus

    Komfortsignatur-Konfigurationsstatus des Konnektors
     
    SIG:ComfortSignatureMax
    Im Konnektor konfigurierte Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen
     
    SIG: ComfortSignatureTimer
    Im Konnektor konfiguriertes Zeitintervall, in dem Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen,
    Format: "PTnHnMnS" (gemäß Datenttyp xsd:duration)
     
    SIG:SessionInfo Falls vorhanden, Session-Informationen zur Komfortsignatursession für das CardHandle und den Aufrufkontext
     
    SIG:SignatureMode Signaturmodus der Komfortsignatursession (="COMFORT")
     

    SIG:CountRemaining
    Verbleibende Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen
    SIG:TimeRemaining Verbleibende Zeit, in der Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen
    Format: "PTnHnMnS" (gemäß Datenttyp xsd:duration)
    Vorbedingungen
    Keine
    Nachbedingungen
    Keine

    Tabelle 251: TAB_KON_882 Ablauf GetSignatureMode

    Nr.


    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung


    1.



    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.  TUC_KON_000 „Prüfe Zugriffsberechtigung“ Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId  = $context.clientsystemId;
        workplaceId = $context.workplaceId;
        userId = $context.userId;
        cardHandle = $cardHandle }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3. TUC_KON_026 „Liefere CardSession“ Ermittle CardSession über TUC_KON_026 {
        mandatId =$context.mandantId;
        clientsystemId  = $context.clientsystemId;
        cardHandle = $context.cardHandle;
        userId = $context.userId }
    4.
    TUC_KON_173 „Liefere Signaturmodus“


    Der Komfortsignatur-Konfigurationsstatus des Konnektors und, falls vorhanden, Session-Informationen zur Komfortsignatursession für das CardHandle und den Aufrufkontext werden zurückgeliefert.
     

    Tabelle 252: TAB_KON_881 Fehlercodes GetSignatureMode

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Folgende Fehlercodes können auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    <=

    4.1.8.6 Betriebsaspekte

    TIP1-A_4680-03

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_596 vorzunehmen:

    Tabelle 253: TAB_KON_596 Konfigurationswerte des Signaturdienstes (Administrator)

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    SAK_SIMPLE_
    SIGNATURE_ MODE
    SE#1
    SE#2
    Aktivierung/Deaktivierung des „Einfachsignaturmodus“ für alle HBAx für die
    Durchführung von Einfachsignaturen im SecurityEnvironment #1 (SE#1) für Dokumentenstapel
    der Größe 1 anstelle der Verwendung des SE#2.
    Default-Wert = SE#1

    SAK_COMFORT_
    SIGNATURE
    Enabled/
    Disabled
    Aktivierung/Deaktivierung der Komfortsignaturfunktion im Konnektor
    Default-Wert = Disabled
    Die Komfortsignaturfunktion darf nur aktiviert sein, wenn
    ANCL_TLS_MANDATORY = Enabled und
    ANCL_CAUT_MANDATORY = Enabled
    SAK_COMFORT_
    SIGNATURE_MAX
    [1 - 250] Anzahl von Komfortsignaturen, die ohne erneute PIN-Eingabe ausgeführt werden dürfen
    Default-Wert = 100
    Der Parameter ist nur relevant, wenn die Komfortsignaturfunktion aktiviert ist (SAK_COMFORT_SIGNATURE = Enabled).

    SAK_COMFORT_
    SIGNATURE_TIMER
    [1 – 24 h] Zeitintervall, in dem Komfortsignaturen ohne erneute PIN-Eingabe ausgeführt werden dürfen
    Der Timer startet mit Eingabe der PIN.QES für die Komfortsignatur.
    Default-Wert = 6 h
    Der Parameter ist nur relevant, wenn die Komfortsignaturfunktion aktiviert ist (SAK_COMFORT_SIGNATURE = Enabled).


    <=

    4.1.9 Zertifikatsdienst

    Der Zertifikatsdienst bietet eine Schnittstelle zur Überprüfung der Gültigkeit von Zertifikaten an. Dies geschieht auf Grundlage des durch den Vertrauensanker (TSL-CA-Signer-Zertifikat und eine aktuelle, gültige TSL aufgespannten Vertrauensraums sowie unter Berücksichtigung von aktuellen Statusinformationen (OCSP, CRL). Die Zertifikatsprüfung wird sowohl für nonQES- als auch für QES-Zertifikate unterstützt.

    Die für die QES-Zertifikatsprüfung notwendigen QES-Signer-Zertifikate werden durch die Vertrauensliste der Bundesnetzagentur (BNetzA-VL) bereitgestellt. Das Signer-Zertifikat der BNetzA-VL ist in der TSL enthalten.

    Im Rahmen der ECC-Migration muss der Konnektor neben RSA auch ECC unterstützen. Hierfür wird eine TSL bereitgestellt, die sowohl die neuen ECC-basierten Zertifikate als auch aus Rückwärtskompatibilitätsgründen die weiterhin benötigten RSA-basierten Zertifikate enthält. Diese neue TSL wird auch als „TSL(ECC-RSA)“ bezeichnet. In dieser Spezifikation wird außerhalb der Regelungen zur ECC-Migration  nicht zwischen „TSL(ECC-RSA)" und „TSL(RSA)" unterschieden, da die Anforderungslage keine Unterscheidung erfordert.

    Innerhalb des Zertifikatsdienstes werden folgende Präfixe für Bezeichner verwendet:

    4.1.9.1 Funktionsmerkmalweite Aspekte

    Bei der Zertifikatsprüfung wird im Rahmen eines Anwendungsfalls u.a. auch der Verwendungszweck des Zertifikats geprüft. Der Verwendungszweck (intendedKeyUsage) wird als Parameter an TUC_KON_037 übergeben. Der konkrete Wert von intendedKeyUsage ist abhängig vom kryptographischen Verfahren, auf welchem das Zertifikat basiert. Die Parametrisierung von intendedKeyUsage wird in TAB_KON_853 in Abhängigkeit vom zu prüfenden Zertifikat, dem Anwendungsfall und dem kryptographischen Verfahren definiert.

    A_17295-01

    Der Konnektor MUSS bei der Zertifikatsprüfung die intendedKeyUsage in Abhängigkeit vom zu prüfenden Zertifikat, dem Anwendungsfall und dem kryptographischen Verfahren gemäß TAB_KON_853 prüfen.

    Tabelle 254: TAB_KON_853- intendedKeyUsage bei Zertifikatsprüfung

    Zertifikat Anwendungsfall intendedKeyUsage bei
    RSA ECC
    C.SMKT.AUT TUC_KON_050 „Beginne Kartenterminalsitzung“
    TUC_KON_053 „Paire Kartenterminal“
    digitalSignature
    &keyEncipherment
    digitalSignature
    C.CH.AUT
    C.CH.AUTN
    TUC_KON_161 „nonQES Dokumentsignatur prüfen” digitalSignature
    &keyEncipherment
    digitalSignature
    C.CH.ENC
    C.CH.ENCV
    C.HCI.ENC
    C.HP.ENC
    Zertifikate  aus CERT_IMPORTED_CA_LIST
    TUC_KON_070 „Daten hybrid verschlüsseln“ keyEncipherment keyAgreement 
     C.HCI.OSIG  TUC_KON_161 „nonQES Dokumentsignatur prüfen”  nonRepudiation  nonRepudiation
    C.FD.TLS-S TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
    digitalSignature&keyEncipherment digitalSignature
    C.ZD.TLS-S TUC_KON_290 „LDAP-Verbindung aufbauen“ digitalSignature digitalSignature
    C.ZD.TLS-S TIP1-A_5662 - Gesicherte Übertragung von BNetzA-VL und Hashwert
    TUC_KON_282 „UpdateInformationen beziehen“
    TUC_KON_283 Infrastruktur Konfiguration aktualisieren
    TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
    TUC_KON_286 „Paket für Fachmodul laden“
    digitalSignature&keyEncipherment digitalSignature
    C.FD.AUT A_17225-* digitalSignature&keyEncipherment digitalSignature
    C.FD.SIG TUC_KON_161 „nonQES Dokumentsignatur prüfen” digitalSignature digitalSignature
    C.FD.OSIG TUC_KON_161 „nonQES Dokumentsignatur prüfen” nonRepudiation nonRepudiation
    C.ZD.SIG TUC_KON_161 „nonQES Dokumentsignatur prüfen” nonRepudiation nonRepudiation
    <=

    Bei der Zertifikatsprüfung wird ein übergebenes Zertifikat oder ein Zertifikat einer referenzierten Karte geprüft. Das konkrete Zertifikatsobjekt einer Karte ist abhängig vom Kartentyp und dem gewählten kryptographischen Verfahren. Die folgende Tabelle führt auf, welche Zertifikatsobjekte einer Karte in Abhängigkeit vom kryptographischen Verfahren für die jeweilige Zertifikatsreferenz ausgewählt werden.

    Tabelle 255: TAB_KON_858 Kartenobjekt in Abhängigkeit vom kryptographischen Verfahren


    CertRef

    Kartentyp
    Objekt der Karte in Abhängigkeit vom kryptographischen Verfahren (Crypt)
    RSA
    ECC
    C.AUT
    HBA-VK 
    EF.C.HP.AUT
    -
    HBA
    EF.C.HP.AUT.R2048
    EF.C.HP.AUT.E256
    SM-B
    EF.C.HCI.AUT
    EF.C.HCI.AUT.E256
    eGK G2
    EF.C.CH.AUT.R2048
    EF.C.CH.AUT.E256
    C.ENC
    HBA-VK
    EF.C.HP.ENC
    -

    HBA
    EF.C.HP.ENC.2048
    EF.C.HP.ENC.E256

    SM-B
    EF.C.HCI.ENC.R2048
    EF.C.HCI.ENC.E256
    C.SIG
    SM-B
    EF.C.HCI.OSIG.R2048
    EF.C.HCI.OSIG.E256
    C.QES
    HBA-VK
    EF.C.HP.QES
    -

    HBA
    EF.C.HP.QES.R2048
    EF.C.HP.QES.E256

    TIP1-A_4682

    Der Vertrauensanker der TI MUSS zum Auslieferungszeitpunkt des Konnektors integritätsgeschützt im Konnektor hinterlegt sein. Zur Sicherstellung dieser Integrität MUSS die Dateiablage EF.C.TSL.CA_1 der Anwendung DF.Sicherheitsanker der gSMC-K [gemSpec_gSMC-K_ObjSys#5.7.2] verwendet werden.

    <=

    TIP1-A_4684

    Falls Parameter MGM_LU_ONLINE=Enabled, MUSS der Zertifikatsdienst einmal täglich die Aktualisierung der TSL durch Aufruf von TUC_KON_032 „TSL aktualisieren“ durchführen und anschließend TUC_KON_040 „CRL aktualisieren“ aufrufen.
    <=

    TIP1-A_4685

    Der Konnektor MUSS Spitzenlasten durch paralleles Herunterladen der TSL und der CRL vermeiden. Dazu MÜSSEN die im Einsatz befindlichen Konnektoren eines Herstellers ihre Download-Versuche gleichmäßig über den Tag verteilen.

    <=

    Dadurch wird gleichzeitig die Spitzenlast bei OCSP-Anfragen begrenzt.

    A_17572

    Falls die TSL(ECC-RSA) verwendet wird, MUSS der Konnektor vor deren Aktualisierung mit TUC_KON_032 „TSL aktualisieren“ die Hash-Datei der TSL(ECC-RSA) herunterladen, um zu prüfen, ob die am TSL-Downloadpunkt verfügbare TSL(ECC-RSA) eine andere ist, als die schon zuvor heruntergeladene und bereits ausgewertete TSL(ECC-RSA). Entspricht der Hash-Wert am Download-Punkt der bereits heruntergeladenen und ausgewerteten TSL(ECC-RSA), MUSS der Konnektor auf den Download verzichten. <=

    A_17661

    Der Konnektor MUSS für den Download der Hash-Datei der TSL(ECC-RSA) die Verbindung zum TSL-Dienst durch TLS absichern. Der Konnektor MUSS das vom TSL-Dienst beim TLS-Verbindungsaufbau präsentierte Zertifikat C.ZD.TLS-S prüfen. Die Prüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ {

    certificate = C.ZD.TLS-S;
    qualifiedCheck = not_required;
    offlineAllowNoCheck = true;
    policyList  = oid_zd_tls_s;
    intendedKeyUsage  = intendedKeyUsage(C.ZD.TLS-S);
    intendedExtendedKeyUsage = id-kp-serverAuth;
    validationMode  = OCSP } .
    Falls Fehler im TLS-Verbindungsaufbau bzw. bei der Zertifikatsprüfung auftreten MUSS der Konnektor den TLS-Verbindungsaufbau mit Fehlercode 4235 gemäß TAB_KON_825 abbrechen.
    <=

    A_17781

    Falls im Rahmen der TSL-Aktualisierung beim Download der Hash-Datei der TSL(ECC-RSA) ein Fehler auftritt MUSS der Konnektor die Aktualisierung der TSL mit TUC_KON_032 „TSL aktualisieren“ ohne einen ermittelten Hashwert aufrufen. <=

    TIP1-A_6730

    Falls Parameter MGM_LU_ONLINE=Enabled, MUSS der Zertifikatsdienst die Aktualisierung der BNetzA-VL im Zeitintervall  CERT_BNETZA_VL_UPDATE_INTERVAL durch Aufruf von TUC_KON_031 „BNetzA-VL aktualisieren durchführen.

    <=

    TIP1-A_6731

    Der Zertifikatsdienst MUSS einmal täglich die zeitliche Gültigkeit der BNetzA-VL prüfen. Wenn das Element NextUpdate in der Vergangenheit liegt MUSS der Konnektor den Betriebszustand EC_ BNetzA_VL_not_valid auslösen.

    <=

    TIP1-A_6732

    Der Konnektor MUSS Spitzenlasten durch Herunterladen der BNetzA-VL vermeiden. Dazu MÜSSEN die im Einsatz befindlichen Konnektoren den Zeitpunkt für den Download zufällig wählen unter Beachtung des konfigurierten Zeitintervalls CERT_BNETZA_VL_UPDATE_INTERVAL.

    <=

    TIP1-A_5662

    Der Konnektor MUSS für den Download der BNetzA-VL und deren Hashwert die Verbindung zum TSL-Dienst durch TLS absichern. Der Konnektor MUSS  das vom TSL-Dienst beim TLS-Verbindungsaufbau präsentierte Zertifikat ID.ZD.TLS_S prüfen. Die Prüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ {

    certificate = ID.ZD.TLS_S;
    qualifiedCheck = not_required;
    offlineAllowNoCheck = true;
    policyList  = oid_zd_tls_s;
    intendedKeyUsage  = intendedKeyUsage(C.ZD.TLS-S);
    intendedExtendedKeyUsage = id-kp-serverAuth;
    validationMode  = OCSP } .
    Fehler im TLS-Verbindungsaufbau bzw. bei der Zertifikatsprüfung führen zum Abbruch des TLS-Verbindungsaufbaus mit Fehlercode 4235 gemäß TAB_KON_825.

    Tabelle 256: TAB_KON_825 Fehlercodes „TLS-Verbindungsaufbau zum TSL-Dienst“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4235
    Security
    Error
    TSL-Dienst konnte bei TLS-Verbindungsaufbau nicht authentisiert werden

    <=

    TIP1-A_5663

    Der Konnektor MUSS beim TLS-Verbindungsaufbau zum TSL-Dienst prüfen, dass die vom TSL-Dienst in ID.ZD.TLS_S übergebene technische Rolle gemäß [gemSpec_OID#GS-A_4446] dem Wert „oid_tsl_ti entspricht.

    Ein Fehler bei der Prüfung der techischen Rolle führt zum Abbruch des TLS-Verbindungsaufbaus mit Fehlercode 4236 gemäß TAB_KON_826.

    Tabelle 257: TAB_KON_826 Fehlercodes TLS-Verbindungsaufbau zum TSL-Dienst bei Prüfung der technischen Rolle

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    4236

    Security

    Error

    Rollenprüfung bei TLS-Verbindungsaufbau zum TSL-Dienst fehlgeschlagen


    <=

    TIP1-A_4686

    Steht der Ablauf der TSL innerhalb von 7 Tagen an, MUSS der Konnektor den Betriebszustand EC_TSL_Expiring annehmen.

    Mit Ablauf der Gültigkeit der TSL MUSS der Konnektor den Betriebszustand EC_TSL_Out_Of_Date_Within_Grace_Period annehmen.

    Mit Ablauf der Graceperiod der TSL MUSS der Konnektor den kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period annehmen.

    <=

    TIP1-A_4687

    Steht der Ablauf der Gültigkeit des TI-Vertrauensankers innerhalb von 30 Tagen an, MUSS der Konnektor den Betriebszustand EC_TSL_Trust_Anchor_Expiring annehmen.

    Mit Ablauf der Gültigkeit des Vertrauensankers MUSS der Konnektor den kritischen Betriebszustand EC_TSL_Trust_Anchor_Out_Of_Date annehmen.

    <=

    TIP1-A_4994

    Steht der Ablauf der Gültigkeit der CRL innerhalb von 3 Tagen an, MUSS der Konnektor den Betriebszustand EC_CRL_Expiring annehmen.

    Mit Ablauf der Gültigkeit der CRL MUSS der Konnektor den kritischen Betriebszustand EC_CRL_Out_Of_Date annehmen.

    <=

    TIP1-A_4688

    Der Konnektor MUSS alle OCSP-Anfragen über den OCSP-Forwarder (HTTP-Proxy) des Zugangsdienst-Providers schicken, der durch die Konfigurationswerte (CERT_OCSP_FORWARDER_ADDRESS, CERT_OCSP_FORWARDER_PORT) festgelegt ist.

    <=

    TIP1-A_4689

    Der Zertifikatsdienst MUSS erhaltene OCSP-Antworten für eine durch CERT_OCSP_DEFAULT_GRACE_PERIOD_NONQES angegebene Anzahl an Minuten (nonQES-Zertifikate) zwischenspeichern.

    <=

    TIP1-A_4690

    Bei Ausführung von TUC_PKI_006 „OCSP-Abfrage“ [gemSpec_PKI#8.3.2.2] MÜSSEN folgende Parameter verwendet werden:

    OCSP-Graceperiod =     
    CERT_OCSP_DEFAULT_GRACE_PERIOD_NONQES

    <=

    TIP1-A_4691

    Für die gSMC-K sowie für jede gesteckte Karte außer eGK MUSS der Konnektor im Intervall CERT_EXPIRATION_CARD_CHECK_DAYS genau einmal TUC_KON_033 aufrufen.
    Der Konnektor MUSS die Gültigkeitsdauer der Zertifikate prüfen mittels Aufruf von:
    für gSMC-K
    TUC_KON_033{checkSMCK; doInformClients=Ja; crypt = ECC}
    TUC_KON_033{checkSMCK; doInformClients=Ja; crypt = RSA}
    für jede gesteckte G2.0 Karte außer eGK und außer gSMC-K
    TUC_KON_033{cardSession; doInformClients=Ja; crypt = RSA}
    für jede gesteckte ab G2.1 Karte außer eGK
    TUC_KON_033{cardSession; doInformClients=Ja; crypt = ECC}
    TUC_KON_033{cardSession; doInformClients=Ja; crypt = RSA}
    <=

    TIP1-A_4692

    Der Konnektor MUSS zur Unterstützung von Missbrauchserkennungen die in Tabelle TAB_KON_597 gelisteten Operationen als Einträge in EVT_MONITOR_OPERATIONS berücksichtigen.

    Tabelle 258: TAB_KON_597 Operationen in EVT_MONITOR_OPERATIONS

    Operationsname
    OK_Val
    NOK_Val
    Alarmwert (Default-Grenzwert 10 Minuten- Σ)
    VerifyCertificate
    1
    5
    401

    <=

    A_23274

    Der Konnektor SOLL dem Administrator an der Management-Oberfläche die Aktualisierung der TSL und CRL per Download ermöglichen. Dabei wird TUC_KON_032 „TSL aktualisieren“ und anschließend TUC_KON_040 „CRL aktualisieren“ aufgerufen. <=

    4.1.9.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.1.9.3 Interne TUCs, nicht durch Fachmodule nutzbar
    4.1.9.3.1 TUC_KON_032 „TSL aktualisieren“

    TIP1-A_4693-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_032 „TSL aktualisieren“ umsetzen.

    Tabelle 259: TAB_KON_766 TUC_KON_032 „TSL aktualisieren“

    Element
    Beschreibung
    Name
    TUC_KON_032 „TSL aktualisieren“
    Beschreibung
    Dieser TUC prüft die Aktualität der TSL und initialisiert ggf. den TSL-spezifischen Bereich des TrustStores neu. Zusätzlich wird bei einem Wechsel des TI-Vertrauensankers das neue TSL-Signer-CA-Zertifikat in einem sicheren Speicherort im Konnektor hinterlegt. Im Fall der Veröffentlichung eines CVC-Root-CA-Zertifikats werden das CVC-Root-CA-Zertifikat und die Cross-CV-Zertifikate aus der TSL in den Truststore eingestellt.
    Auslöser
    • Aufruf durch andere TUCs
    Vorbedingungen
    • Ein gültiger TI-Vertrauensanker ist vorhanden
    • Das XML-Schema der TSL-Datei liegt vor
    Eingangsdaten
    • importedTSL – optional
      (TSL aus aus manuellem Import) (Optional)
    • baseTime – optional; default: aktuelles Datum
      (Referenzzeitpunkt) ()
    • onlineMode [ENABLED | DISABLED]
      (Flag „MGM_LU_ONLINE“ für Offline/Online-Modus)
    • hashTSL - optional
      (Hashwert-Datei der TSL im System; gilt nur für TSL(ECC-RSA))
    Komponenten
    Konnektor
    Ausgangsdaten
    • result
      (Status der Prüfung)
    • newHashTSL - optional; verpflichtend für TSL(ECC-RSA)
      (Hashwert-Datei der TSL im System; gilt nur für TSL(ECC-RSA))
    Nachbedingungen
    • Aktuelle TSL-Informationen inkl. des Vertrauensankers der BNetzA VL und sämtlicher CVC-Root-CA- und Cross-CV-Zertifikate liegen im Truststore vor.
    • Ein ggf. gelieferter neuer Vertrauensanker der TI ist in einem sicheren Speicherort gespeichert
    Standardablauf
    1. Der Konnektor prüft und aktualisiert ggf. die TSL durch Aufruf von TUC_PKI_001. Der Konnektor verwendet bei der Aktualisierung der TSL standardmäßig die Download-Punkte in der TI.
      Der durch den dort aufgerufenen TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“ benötigte aktuelle TI-Vertrauensanker befindet sich auf der gSMC-K in der Datei EF.C.TSL_CA_1 oder in einem sicheren Speicherort im Konnektor. Es ist dasjenige Zertifikat zu verwenden, welches zum Referenzzeitpunkt gültig ist und ab dem Aktivierungsdatum (StatusStartingTime des neuen TSL-Signer-CA-Zertifikats) aktiviert ist.
    2. Ggf. vorhandene CVC-Root-CA-Zertifikat und Cross-CV-Zertifikate werden genauso wie und zusammen mit den anderen CA-Zertifikaten aus der TSL extrahiert.
    3. Alle Informationen aus der TSL werden im TSL-spezifischen Bereich des TrustStores gespeichert
    4. Der Konnektor löst TUC_KON_256 {
          topic = „CERT/TSL/UPDATED”;
          eventType = Op;
          severity = Info;
          doLog = true;
          doDisp = false }
      aus.
    5. CERT_CRL_DOWNLOAD_ADDRESS wird mit den CRL-Download-Adressen aus der TSL überschrieben.
    Varianten/
    Alternativen
    (-> 1) Wenn der Download der TSL aus der TI fehlschlägt oder wenn der Konnektor im Fall onlineMode = ENABLED keine Verbindung zur TI hat, muss der Konnektor die TSL vom Download-Punkt im Internet (CERT_TSL_DOWNLOAD_ADDRESS_INTERNET) gemäß [gemSpec_TSL#A_21182] beziehen. Im Fall onlineMode = DISABLED wird abgebrochen.
    Wenn kein aktiver VPN-Tunnel SIS vorhanden ist, muss der Konnektor den Downloadversuch der TSL aus dem Internet direkt über das IAG initiieren, auch wenn ANLW_INTERNET_MODUS=SIS konfiguriert ist. Im Fall ANLW_INTERNET_MODUS=KEINER wird abgebrochen.
    Wenn die Namensauflösung für CERT_TSL_DOWNLOAD_ADDRESS_INTERNET fehlschlägt, muss der Konnektor die TSL über CERT_TSL_IP_ADDRESS_INTERNET beziehen.
    Wenn keiner der vorigen Downloadversuche erfolgreich war, muss der Konnektor die TSL von der konfigurierbaren Adresse CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU beziehen.
    Wenn die Namensauflösung für CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU fehlschlägt, muss der Konnektor die TSL über CERT_TSL_IP_ADDRESS_INTERNET_BU beziehen.
    Für eine aus dem Internet bezogene TSL muss der Konnektor auch die vom TSL-Dienst gemäß [gemSpec_TSL#A_21182] bereitgestellte detached-Signatur der TSL herunterladen. Der Konnektor muss dann immer zunächst die detached-Signatur der TSL prüfen, einschließlich vollständiger Prüfung der Zertifikatskette bis zum TI-Vertrauensanker. Die kryptographische Prüfung der Signatur muss entsprechend A_21185 durchgeführt werden.
    Bezüglich der Prüfung des Sperrstatus des TSL-Signer-Zertifikats muss der Konnektor eines der folgenden Verfahren umsetzen:
    1. Der Konnektor lädt die vorgefertigte OCSP-Response für das TSL-Signer Zertifikat aus dem Internet herunter (vgl. [gemSpec_TSL#A_21182]). Bei der Prüfung dieser OCSP-Response entfällt die Auswertung gegen die im System konfigurierte OCSP-Graceperiod. Der Konnektor prüft, dass die vorgefertigte OCSP-Response nicht älter als 61 Minuten ist. Die OCSP-Abfrage für das TSL-Signer Zertifikat in TUC_PKI_001, Schritt 4 entfällt.
      oder
    2. Standard OCSP-Abfrage für das TSL-Signer Zertifikat in TUC_PKI_001, Schritt 4, jedoch unter Verwendung des im Internet verfügbaren OCSP-Responders entsprechend [gemSpec_TSL#TIP1-A_4076-01].
    (1) Wird die importedTSL manuell übergeben (in den Eingangsdaten), so wird diese statt des Downloads verwendet und an TUC_PKI_001 übergeben. Innerhalb der PKI TUCs findet dann kein Download der TSL statt.
    (1) Falls onlineMode = DISABLED, kann der Sperrstatus des TSL-Signer-Zertifikats nicht überprüft werden. In diesem Fall wird die Aktivierung der importedTSL auch ohne Prüfung des Sperrstatus durchgeführt.
    (1) Wird durch den von TUC_PKI_001 aufgerufenen TUC_PKI_013 „Import neuer Vertrauensanker“ ein neuer TI-Vertrauensanker (ein neues TSL-Signer-CA-Zertifikat) in der importedTSL gefunden, so wird dieser, wie dort beschrieben, extrahiert und in einem sicheren Speicherort gespeichert. Vor Erreichen des Aktivierungsdatums werden die TSLs ausschließlich mit dem alten TSL-Signer-Zertifikat signiert. Ab dem Aktivierungsdatum werden die TSLs mit einem TSL-Signer-Zertifikat signiert, das von der neuen TSL-Signer-CA ausgestellt wurde.
    Fehlerfälle
    (1) Tritt beim manuellen Import der Datei ein Fehler auf, wird TUC_KON_256 {
           topic = „CERT/TSL/IMPORT“;
           eventType = Op;
           severity = Error;
           parameters = „$Fehlerbeschreibung“;
           doLog = true;
           doDisp = false }
    ausgelöst. Fehlercode 4128.
    (1) Tritt beim periodischen Update der TSL beim Aufruf des TUC_PKI_001 oder eines durch ihn aufgerufenen TUCs ein Fehler auf, geht der Konnektor in den Betriebszustand EC_TSL_Update_Not_Successful. Der Konnektor geht erst in den Betriebszustand EC_TSL_Update_Not_Successful, wenn weder der Downloadversuch aus der TI noch der Downloadversuch aus dem Internet erfolgreich war. Die vorhandenen TSL-Vertrauensanker werden weiter verwendet. Fehlercode 4127.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 260: TAB_KON_598 Fehlercodes TUC_KON_032 „TSL aktualisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4127
    Security
    Error
    Import der TSL-Datei fehlgeschlagen
    4128
    Technical
    Error
    der manuelle Import der TSL-Datei schlägt fehl

    <=

    Für den Download der TSL über einen HTTP-Server im Internet wird zusätzlich zu der bereits mit einer XML-Signatur versehenen TSL eine detached-Signatur als separate Datei auf dem Download-Punkt zur Verfügung gestellt. Diese detached-Signatur umfasst die TSL in ihrerer Gänze, das heißt die TSL-XML-Datei wird inkl. der dort bereits enthaltenen XML-Signatur nochmal durch den TSL-Signer signiert. Ein Konnektor verwendet dann bei der Signaturprüfung einer TSL, die über das Internet bezogen wurde, die detached-Signatur für die Signaturprüfung. Hintergrund ist die aus Sicherheitsperspektive einfachere, im Sinne von sicherer prüfbare detached-Signatur. Das heißt, die TSL muss nicht als XML-File verarbeitet und die relativ komplexe XML-Signatur - die potentiell von einem Angreifer modifiziert sein könnte - nicht ausgewertet werden. Deshalb wird der Weg gewählt, der auch für die Signatur von X.509-Zertifikaten und OCSP-Responses verwendet wird.

    A_21185

    Der Konnektor MUSS beim Download der TSL aus dem Internet ebenfalls deren detached-Signatur (vgl. [gemSpec_TSL#A_21182]) mit herunterladen und immer zunächst folgende Prüfungen durchführen:

    1. Prüfung, dass die heruntergeladene detached-Signatur-Datei den folgenden Aufbau aufweist:
      Sequence aus drei Elementen:
        SEQUENCE {
          
      a
          
      b
          
      c}
      Mit a, b und c wie folgt:
      1. OID für den Signaturtyp, bestehend aus
        1. im Falle ECDSA:
              SEQUENCE {OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)}
        2. im Falle RSASSA-PSS:
              SEQUENCE {OBJECT IDENTIFIER rsaPSS (1 2 840 113549 1 1 10)
                SEQUENCE {
                  [0] {SEQUENCE {OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)}}
                  [1] {SEQUENCE {
                            OBJECT IDENTIFIER pkcs1-MGF (1 2 840 113549 1 1 8)
                            SEQUENCE {OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)}}}
                  [2] {INTEGER 32}}}

      2. Kryptographische Signatur
        1. im Falle ECDSA:
          einer ECDSA-Signatur nach [BSI-TR-03111#5.2.2.]
        2. im Falle RSASSA-PSS:
          eine RSASSA-PSS-Signatur nach [RFC-8017] (reiner ASN.1-kodierter Signaturwert – die OID ist schon in Teil a.ii. aufgeführt)
      3. Zertifikat des Signierenden (TSL-Signer)
        1. im Falle ECDSA:
          genau nur das ECC-TSL-Signer-Zertifikat
        2. im Falle RSASSA-PSS:
          genau nur das RSA-TSL-Signer-Zertifikat
    2. Prüfung der Signatur (1b) gegen das TSL-Signer-Zertifikat (1c).
    Schlägt eine der Prüfungen fehl, MUSS der Import abgebrochen werden.
    Ist die Prüfung erfolgreich, KANN die Prüfung der XML-Signatur der TSL im weiteren fachlichen Ablauf der TSL-Aktualisierung entfallen.
    <=

    Eine erweiterte Übersicht zum Aufbau der detached-Signatur-Datei inkl. Beispiel finden sie unter [gemGitHub_tslSig].

    A_20750

    Der Hersteller des Konnektors MUSS den Betreiber des Konnektors in geeigneter Weise (mindestens per Handbuch-Eintrag und per Hinweis innerhalb der UpdateInformation eines FirmwareUpdates am KSR) darüber informieren, dass im Fall, dass eine TSL-Aktualisierung innerhalb der TI fehlschlägt, automatisch versucht wird, eine TSL-Aktualisierung aus dem Internet vorzunehmen. <=

    4.1.9.3.2 TUC_KON_031 „BNetzA-VL aktualisieren“

    TIP1-A_6729

    Der Konnektor MUSS den technischen Use Case TUC_KON_031 „BNetzA-VL aktualisieren“ umsetzen.

    Tabelle 261: TAB_KON_618 TUC_KON_031 „BNetzA-VL aktualisieren“

    Element
    Beschreibung
    Name
    TUC_KON_031 „BNetzA-VL aktualisieren”
    Beschreibung
    Dieser TUC prüft die Aktualität der BNetzA-VL. Wenn eine neuere BNetzA-VL vorliegt, wird diese heruntergeladen, geprüft und im Truststore gespeichert.
    Auslöser
    • Aufruf durch andere TUCs
    • TIP1-A_6728
    Vorbedingungen
    • Aktuell gültige TSL im Truststore vorhanden
    Eingangsdaten
    • BNetzA-VL aus manuellem Import (Optional)
    • Flag „MGM_LU_ONLINE“ für Offline-/Online-Modus
    • Flag „MGM_LU_SAK“ für Signaturdienst-Modus
    Komponenten
    Konnektor
    Ausgangsdaten
    • Status der Prüfung
    Nachbedingungen
    • Aktuelle BNetzA-VL und deren Hashwert liegen im Truststore vor.
    Standardablauf
    1.      Der Konnektor prüft und aktualisiert ggf. die BNetzA-VL durch Aufruf von TUC_PKI_036.
    2.      Der Konnektor löst TUC_KON_256 {"CERT/BNETZA_VL/UPDATED"; Op; Info; „"; doLog = true; doDisp = false} aus.
    Varianten/Alternativen
    (1) Wird eine zu importierende BNetzA-VL manuell übergeben (in den Eingangsdaten), so wird diese statt des Downloads verwendet und an TUC_PKI_036 {BNetzA-VL Datei} übergeben. Innerhalb der PKI TUCs findet dann kein Download der BNetzA-VL statt.
    (1) Ist MGM_LU_SAK=disabled, so wird der TUC ohne Fehler beendet.
    Fehlerfälle
    (1) Tritt beim manuellen Import der Datei ein Fehler auf, wird TUC_KON_256 {„CERT/BNETZA_VL/IMPORT“; Op; Error; „$Fehlerbeschreibung“; doLog = true; doDisp = false} ausgelöst. Fehlercode 4129.
    (1) Tritt beim periodischen Update der BNetzA-VL beim Aufruf des TUC_PKI_036 oder eines durch ihn aufgerufenen TUCs ein Fehler auf, geht der Konnektor in den Betriebszustand EC_BNetzA_VL_Update_Not_Successful. Fehlercode 4133.
    In beiden Fällen wird eine vorhandene gültige BNetzA-VL weiter verwendet.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 262: TAB_KON_619 Fehlercodes TUC_KON_031 „BNetzA-VL aktualisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4129
    Technical
    Error
    der manuelle Import der BNetzA-Vertrauensliste schlägt fehl
    4133
    Security
    Error
    Import der BNetzA-Vertrauensliste fehlgeschlagen

    <=

    4.1.9.3.3 TUC_KON_040 „CRL aktualisieren“

    TIP1-A_4694

    Der Konnektor MUSS den technischen Use Case TUC_KON_040 „CRL aktualisieren“ umsetzen.

    Tabelle 263: TAB_KON_767 TUC_KON_040 „CRL aktualisieren“

    Element
    Beschreibung
    Name
    TUC_KON_040 „CRL aktualisieren“
    Beschreibung
    Dieser TUC aktualisiert die CRL
    Auslöser
    • Aufruf durch andere TUCs
    Vorbedingungen
    • Ein gültiger Vertrauensraum
    Eingangsdaten
    • importedCRL – optional
      (Manuell importierte CRL)

    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Nachbedingungen
    • Eine aktuelle, gültige CRL liegt vor
    Standardablauf
    1.      Der Konnektor lädt die aktuelle CRL von CERT_CRL_DOWNLOAD_ADDRESS herunter.
    2.      Die Prüfung der CRL-Signatur mit dem CRL-Signer-Zertifikat setzt sich aus folgenden Teilschritten zusammen
      1.       Prüfung auf zeitliche Gültigkeit des CRL-Signer-Zertifikats mittels TUC_PKI_002 "Gültigkeitsprüfung des Zertifikats" mit Referenzzeitpunkt = aktuelle Systemzeit
      2.       Auswahl des öffentlichen Schlüssels des CRL-Signer-Zertifikats (CRL-Signer-Zertifikat im Truststore)
      3.       Die Signatur und der verwendete Algorithmus werden aus der  CRL ausgelesen
      4.       Verifikation der Signatur und Hashwert-Vergleich (Verfahren siehe [RFC5280]).
        Falls die Prüfung ein negatives Ergebnis erbracht hat, löst der
        Konnektor das Ereignis TUC_KON_256 {
               topic = „CERT/CRL/INVALID“;
               eventType = Op;
               severity = Error;
               parameters = „„;
               doLog = true;
               doDisp = false }
        aus.
    1.      Nach einer erfolgreichen Prüfung speichert der Konnektor die neue CRL und löst das Ereignis TUC_KON_256{
                  topic = „CERT/CRL/UPDATED“;
                  eventType = Op;
                  severity = Error;
                  parameters = „„;
                  doLog = true;
                  doDisp=false}
    aus.
    1.       Falls die aktuelle Systemzeit den Wert NextUpdate aus der CRL erreicht oder überschritten hat, geht der Konnektor in den Betriebszustand EC_CRL_Out_Of_Date.
    Varianten/
    Alternativen

    (1) Wird eine manuell importierte CRL übergeben, so wird diese verwendet.
    Fehlerfälle
    (1) Tritt beim manuellen Import der Datei ein Fehler auf, wird TUC_KON_256 {
            topic = „CERT/CRL/IMPORT“;
            eventType = Op;
            severity = Error;
            parameters = „${Fehlerbeschreibung}“;
            doLog = true;
            doDisp=false}
    ausgelöst.

    (2) Signaturprüfung der CRL fehlgeschlagen: Fehlercode 4130
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 264: TAB_KON_599 Fehlercodes TUC_KON_040 „CRL aktualisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4130
    Security
    Error
    Signatur- oder Gültigkeitsprüfung der CRL fehlgeschlagen

    <=

    4.1.9.3.4 TUC_KON_033 „Zertifikatsablauf prüfen“

    TIP1-A_4695

    Der Konnektor MUSS den technischen Use Case TUC_KON_033 „Zertifikatsablauf prüfen” umsetzen.

    Tabelle 265: TAB_KON_768 TUC_KON_033 „Zertifikatsablauf prüfen“

    Element
    Beschreibung
    Name
    TUC_KON_033 „Zertifikatsablauf prüfen“
    Beschreibung
    Dieser TUC prüft und meldet das zeitliche Ablaufen eines X.509-Zertifikats einer Karte.
    Auslöser
    • Aufruf durch andere TUCs des Konnektors oder
    • über die Managementschnittstelle
    Vorbedingungen
    Keine
    Eingangsdaten
    • cardSession – optional/für eGK, HBA, SM-B, gSMC-KT
    • checkSMCK [Boolean] – optional/für gSMC-K;
      (Referenz auf eine/die gSMC-K, alternativ zu cardSession)
    • doInformClients [Boolean]
      (Angabe, ob ein Event an die Clients gesendet werden soll)
    • crypt - optional; default = RSA
      (kryptographischer Algorithmus, für welchen das Zertifikat ermittelt wird;
      Wertebereich: ECC, RSA)
    Komponenten
    Konnektor
    Ausgangsdaten
    • expirationDate
      (Ablaufdatum des untersuchten Zertifikats)
    Standardablauf
    1. TUC_KON_216 „LeseZertifikat“ für:
      • Bei checkSMCK das Zertifikat der gSMC-K (C.NK.VPN) gemäß TAB_KON_856
      • bei CardSession die Zertifikate der identifizierten Karte.
        1. Für die eGK: C.CH.AUT
        2. Für den HBAx: C.HP.AUT
        3. Für SM-B: C.HCI.AUT
      • Das konkrete Zertifikatsobjekt der Karte gemäß TAB_KON_858 wird vom Eingangsparameter crypt abgeleitet.
    2. Das Ablaufdatum expirationDate wird aus dem Feld validity ausgelesen.
    3. Falls das Zertifikat abgelaufen ist, Systemereignis absetzen:
    • gSMC-K:
      TUC_KON_256 {
            topic = „CERT/CARD/EXPIRATION”;
            eventType = Op;
            severity = Warning;
            parameters = („CARD_TYPE=gSMC-K,  
                 ICCSN=$ICCSN,
                 Konnektor=$MGM_KONN_HOSTNAME,
                 ZertName=$Name des Zertifikatsobjekts gemäß TAB_KON_856,
                  ExpirationDate=$validity");
            doLog = true;
            doDisp = $doInformClients }
    • Sonstige Karten (mit CARD(CardSession)):
      TUC_KON_256 {
            topic = „CERT/CARD/EXPIRATION”;
            eventType = Op;
            severity = Warning;
            parameters = („CARD_TYPE=$Type,
                ICCSN=$ICCSN,
                CARD_HANDLE=$CardHandle,
                CardHolderName=$CardHolderName,
                ZertName=$Name des Zertifikatsobjekts aus Schritt 1,
                ExpirationDate=$validity“);
            doLog=false;
            doDisp = $doInformClients }
    4. Alternativ bei Ablauf des Zertifikats innerhalb von CERT_EXPIRATION_WARN_DAYS Systemereignis absetzen:
    • gSMC-K:
      TUC_KON_256 {
           topic = „CERT/CARD/EXPIRATION”;
            eventType = Op;
            severity = Info;
            parameters = („CARD_TYPE=gSMC-K, 
                ICCSN=$ICCSN,
                Konnektor=$MGM_KONN_HOSTNAME,
                ZertName=$Name des Zertifikatsobjekts gemäß TAB_KON_856,     
                ExpirationDate=$validity,
                DAYS_LEFT=$validity-$Today“);
            doLog = false;
            doDisp = $doInformClients}
    •  Sonstige mit CARD(CardSession)):
      TUC_KON_256 {
            topic = „CERT/CARD/EXPIRATION”;
            eventType = Op;
            severity = Info;
            parameters = („CARD_TYPE=$Type,
                ICCSN = $ICCSN,
                CARD_HANDLE = $CardHandle,
                CardHolderName = $CardHolderName,
                ZertName=$Name des Zertifikatsobjekts aus Schritt 1,
                ExpirationDate = $validity,
                DAYS_LEFT = $validity-$Today“);
            doLog = false;
            doSisp = $doInformClients}
    5. expirationDate wird zurückgegeben.

    Varianten/
    Alternativen
    Keine
    Fehlerfälle
    (1) Zur angegebenen CardSession keine Karte gefunden: Fehlercode 4131.
    (1) Für eGK, HBA, SM-B gilt: Wenn crypt=ECC und Kartengeneration<G2.1, bricht der TUC mit Warnung 4257 ab.
    (1) Für gSMC-K gilt: Wenn crypt=ECC und beim Aufruf von TUC_KON_216 wird die Warnung 4256 zurückgegeben, dann wird der TUC nach Schritt 1 beendet und die Warnung 4257 an den Aufrufer zurückgegeben.
    (2) Extraktion des Ablaufsdatums fehlgeschlagen: Fehlercode 4132.
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine


    Tabelle 266: TAB_KON_600 Fehlercodes TUC_KON_033 „Zertifikatsablauf prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4131
    Technical
    Error
    Zum angegebenen CardHandle keine Karte gefunden.
    4132
    Security
    Error
    Extraktion des Ablaufsdatums fehlgeschlagen
    4257 Technical Warning ECC-Zertifikate nicht vorhanden auf Karte: <cardHandle>

    <=

    4.1.9.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.9.4.1 TUC_KON_037 „Zertifikat prüfen"

    TIP1-A_4696-02

    Der Konnektor MUSS den technischen Use Case „Zertifikat prüfen“ gemäß TUC_KON_037 „Zertifikat prüfen“ umsetzen.

    Tabelle 267: TAB_KON_769 TUC_KON_037 „Zertifikat prüfen“

    Element
    Beschreibung
    Name
    TUC_KON_037 „Zertifikat prüfen“
    Beschreibung
    Der TUC beschreibt
    • die Prüfung eines X.509-Zertifikats gegen den Vertrauensraum
    Auslöser
    • Aufruf in einem Fachmodul oder
    • technischen Use Case
    Vorbedingungen
    • aktuelle TSL-Informationen im Truststore vorhanden
    • für QES X.509-Prüfung: eine aktuell gültige BNetzA-VL
    Eingangsdaten
    • certificate
      (ein X.509-Zertifikat (nonQES- oder QES-X.509-Zertifikat))
    • EECertificateContainedInTSL - optional; default: false
      (true: Prüfung, ob ein EE-Zertifikat in der TSL vorhanden und zeitlich gültig ist; EE-Zertifikat wird in der TSL innerhalb eines "TSPService"-Eintrags ServiceTypeIdentifier "http://uri.etsi.org/TrstSvc/Svctype/unspecified " erwartet.
      false: vollständige Prüfung eines X.509-Zertifikats mit TUC_PKI_018 bzw. TUC_PKI_030)
    • qualifiedCheck [not_required | required | if_QC_present] –
      (Art der Zertifikatsprüfung)
    • baseTime – optional/verpflichtend, wenn ein Zeitpunkt zur Prüfung vorgegeben werden soll; default: Verwendung der Systemzeit des Konnektors
      (Referenzzeitpunkt: Zeitpunkt, für den das Zertifikat geprüft werden soll)
    • offlineAllowNoCheck [Boolean] – optional; default: false
      (Angabe, ob es als Fehler (false) oder als Warnung (true) interpretiert werden soll, wenn eine OCSP-Prüfung nicht durchgeführt werden konnte.)
    • intendedKeyUsage – optional/verpflichtend, wenn  certificate ein nonQES-X.509-Zertifikat ist; wird bei QES nicht ausgewertet
      (Vorgesehene KeyUsage)
    • nur für nonQES-Zertifikate:
      • policyList
        (Liste der zugelassenen Zertifikatstyp-OIDs gemäß [gemSpec_OID#GS-A_4445])
      • intendedExtendedKeyUsage – optional/verpflichtend, wenn certificate ein nonQES-X.509-Zertifikat ist; wird bei QES nicht ausgewertet
        (Vorgesehene ExtendedKeyUsage)
      • gracePeriod – optional/nur für nonQES-X.509-Zertifikat und wenn vom Standard abgewichen werden soll; wird bei QES nicht ausgewertet; default: CERT_OCSP_DEFAULT_GRACE_PERIOD_NONQES
        (OCSP-GracePeriod: maximal zulässiger Zeitraum, den letzte OCSP-Antwort aus dem Cache bezüglich des Referenzzeitpunkts zurückliegen darf;)
      • validationMode [OCSP | CRL | NONE] – optional/verpflichtend, wenn  certificate ein nonQES-X.509-Zertifikat ist
        (Prüfmodus:
        • OCSP: Es wird mittels OCSP geprüft. Dabei wird, falls die OCSP-GracePeriod noch nicht abgelaufen ist, die OCSP-Antwort aus dem Cache des Konnektors verwendet. Für QES einzig erlaubter validationMode.
        • CRL: Es wird gegen die aktuelle CRL auf dem Konnektor geprüft.
        • NONE: Keine Prüfung von Statusinformationen)
    • ocspResponse – optional  
      (OCSPResponse des EE-Zertifikats)
    • getOCSPResponses [Boolean]– optional; default: false
      (true – OCSPResponse des geprüften Zertifikats soll an den Aufrufer zurückgegeben werden)
    Komponenten
    Konnektor
    Ausgangsdaten
    • Status und Liste von Warnungen/Fehlern bei der Zertifikatsprüfung
    • role
      (aus dem Zertifikate ermittelte Rolle oder Berufsgruppe; siehe „Tab_PKI_406 OID-Festlegung technische Rolle in X.509-Zertifikaten“ oder „Tab_PKI_402 OID-Festlegung Rolle im X.509-Zertifikat für Berufsgruppen“ oder Tab_PKI_403 OID-Festlegung Institutionen im X.509-Zertifikat der SMC-B [gemSpec_OID])
    • qcStatement – optional/verpflichtend, wenn  certificate ein QES-X.509-Zertifikat ist;
      nicht relevant bei EECertificateContainedInTSL=true.

      (QCStatements des Zertifikats)
    • ocspResponsesRenewed – optional/verpflichtend, wenn Eingabeparameter getOCSPResponses = true;
      nicht relevant bei EECertificateContainedInTSL=true.

      (OCSP-Response des geprüften Zertifikats)
    Standardablauf
    1. Falls EECertificateContainedInTSL=false:
      1. Wenn das X.509-Zertifikat von einem CA-Zertifikat ausgestellt wurde, das in CERT_IMPORTED_CA_LIST enthalten ist, erfolgt eine Zertifikatsprüfung analog zu den Festlegungen in TUC_PKI_018 „Zertifikatsprüfung”.
        Dabei sind zu prüfen:
        - Zeitliche Gültigkeit,
        - Gültigkeit des EE-Zertifikats nach Kettenmodell (analog zu z. B. [gemKPT_PKI_TIP#2.4.3]) 
        - mathematische Prüfung der Zertifikatssignatur,
        - die Prüfung der Zweckbindung gemäß der im Zertifikat hinterlegten keyUsage
        TSL-bezogene Prüfungen im TUC_PKI_018 werden in diesem Fall nicht durchgeführt. Ebenso erfolgt keine OCSP-Prüfung.
      2. Wenn das zum X.509-Zertifikat gehörende CA-Zertifikat nicht in CERT_IMPORTED_CA_LIST enthalten ist, werden, abhängig vom Parameter qualifiedCheck folgende TUCs unter Weitergabe aller Eingangsparameter sowie der Negation des Werts von MGM_LU_ONLINE als Parameter „Offline-Modus“ aufgerufen:
        1. Für qualifiedCheck = not_required: TUC_PKI_018 „Zertifikatsprüfung in der TI”
          Ist der Eingangsparameter ocspResponses mit einer OCSP-Antwort gefüllt, so wird dieser übergeben. Die aktuell aus der OCSP-Abfrage resultierte OCSP-Antwort, falls vorhanden, wird an den Aufrufer weitergegeben.
        2. Für qualifiedCheck = required: TUC_PKI_030 „QES-Zertifikatsprüfung“
          Dabei wird das Basiszertifikat übergeben. Ist Eingangsparamter ocspResponses mit einer OCSP-Response gefüllt, so wird dieser übergeben. Die aktuell aus der OCSP-Abfrage resultierende OCSP-Response, falls vorhanden, wird an den Aufrufer weitergegeben.
        3.  Für qualifiedCheck = if_QC_present: Ist im jeweiligen Signaturzertifikat mindestens ein QCStatement mit dem OID id-etsi-qcs-QcCompliance (0.4.0.1862.1.1) enthalten, handelt es sich um eine QES-Zertifikatsprüfung mittels TUC_PKI_030 „QES-Zertifikatsprüfung“, sonst um eine nonQES-Zertifikatsprüfung mittels TUC_PKI_018 „Zertifikatsprüfung".
    Als Timeout wird beim Aufruf von TUC_PKI_018  der Wert von CERT_OCSP_TIMEOUT_NONQES bzw. beim Aufruf von TUC_PKI_030 der Wert von CERT_OCSP_TIMEOUT_QES übergeben (siehe auch Eingangsdaten von diesen TUCs in [gemSpec_PKI]).
    Für die QES-Zertifikatsprüfung wird das zu prüfende QES-Zertifikat an TUC_PKI_030 „QES-Zertifikatsprüfung“ übergeben.
    Wird im Aufruf der Eingangsparameter getOCSPResponses = false mit übergeben, wird keine OCSP-Response an den Aufrufer zurückgegeben.
    Als TOLERATE_OCSP_FAILURE wird beim Aufruf von TUC_PKI_018  offlineAllowNoCheck verwendet.

    Wenn der Eingangsparameter validationMode („Prüfmodus“) den Wert NONE hat, werden die TUC_PKI_018-Eingangsparameter
    • „Offline-Modus“ unabhängig von
      MGM_LU_ONLINE auf „ja“ gesetzt und
    • „Prüfmodus“ auf „OCSP“.
    1. Falls EECertificateContainedInTSL=true
      1. Prüfe, ob das in certificate übergebene X.509-Zertifikat in der TSL innerhalb eines "TSPService"-Eintrags mit dem ServiceTypeIdentifier "http://uri.etsi.org/TrstSvc/Svctype/unspecified" aufgeführt ist.
      2. Prüfe zeitliche Gültigkeit von certificate zum Prüfzeitpunkt aktuelle Systemzeit durch Aufruf von TUC_PKI_002.
      3. Ermittle role von certificate durch Aufruf von TUC_PKI_009.
    2. Der Status der Prüfung und die ermittelten Ausgangsdaten werden zurückgegeben.

    Varianten/
    Alternativen

    Fehlerfälle
    TUC_KON_037 im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period aufgerufen: Fehlercode 4002.
    -> 2a) certificate ist nicht in der TSL enthalten
    Nichtfunktionale Anforderungen
    Der Konnektor MUSS unter Einhaltung aller anderen Anforderungen an die Zertifikatsprüfung die Anzahl der OCSP-Abfragen minimieren. Dies MUSS durch Caching (unter Berücksichtigung der Grace Period) und DARF NICHT durch Bündelung von OCSP-Anfragen geschehen.
    Zugehörige
    Diagramme
    keine


    Tabelle 268: TAB_KON_601 Fehlercodes TUC_KON_037 „Zertifikat prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases treten folgende Fehlercodes auf.
    4002
    Security
    Fatal
    Der Konnektor befindet sich in einem kritischen Betriebszustand
    4260 Security Error Zertifikat nicht vorhanden in TSL
    <=

    4.1.9.4.2 TUC_KON_042 „CV-Zertifikat prüfen“

    TIP1-A_5482-01

    Der Konnektor MUSS den technischen Use Case „CV-Zertifikat prüfen“ gemäß TUC_KON_042 „CV-Zertifikat prüfen“ umsetzen.

    Tabelle 269: TAB_KON_818 TUC_KON_042 „CV-Zertifikat prüfen“ 

    Element
    Beschreibung
    Name
    TUC_KON_042 „CV-Zertifikat prüfen“
    Beschreibung
    Die Gültigkeit eines (EndEntity-)CV-Zertifikats wird geprüft. Es werden folgende Prüfungen durchgeführt:
    Kryptographische Prüfung der Signaturen des End-Entity-CV-Zertifikats und des CVC-CA-Zertifikats
    •     Zeitliche Gültigkeit nach dem Schalenmodell (nur CV-Zertifikate der Generation 2).
    Auslöser
    •     Aufruf in einem Fachmodul oder
    •     Technischen Use Case
    Vorbedingungen
    •      keine
    Eingangsdaten
    •     eeCertificate
      (zu prüfendes kartenindividuelles CV-Zertifikat)
    •     caCertificate
      (das CVC-CA-Zertifikat mit dem öffentlichen Schlüssel der zugehörigen ausstellenden CA)
    Komponenten
    Konnektor
    Ausgangsdaten
    •     status [Boolean]
          (Ergebnis der Prüfung;
              true: CV-Zertifikat ist gültig
              false: CV-Zertifikat ist ungültig)
    Standardablauf
    1.  Prüfung von CV-Zertifikaten der Generation 2:
        Die CVC-Prüfung setzt sich gemäß GS-A_5009, … GS-A_5012
       [gemSpec_PKI#8.8] aus folgenden Schritten zusammen:
            i. Prüfe die kryptographische Korrektheit der Signatur des
                   CA-Zertifikats caCertificate mit dem öffentlichen Root-
                   Schlüssel der ausstellenden CVC-Root-CA. Der benötigte
                  Root-Key befindet sich im Truststore des Konnektors.
            ii. Prüfe die kryptographische Korrektheit der Signatur des
                   (EndEntity-)CV-Zertifikats certificate mit dem öffentlichen
                  Schlüssel der ausstellenden CVC-CA (aus dem CVC-CA-
                   Zertifikat extrahiert).
           iii. Prüfe die zeitliche Gültigkeit des (EndEntity-)CV-Zertifikates,
                   des CVC-CA-Zertifikates und CVC-Root-CA-Zertifikates
                  nach dem Schalenmodell.
       2. Der Status status der Prüfung wird zurückgegeben.
    Varianten/Alternativen
    ( i) Mathematische Korrektheitsprüfung CV-Zertifikate mit Cross-CV-Zertifikat (vgl. Varianten/Alternativen von TUC_KON_005)
    Fehlerfälle
    ( i) das benötigte Cross-CV-Zertifikat ist nicht vorhanden, Fehlercode 4228
    ( i) kryptographische (mathematische) Prüfung des CVC-CA-Zertifikats fehlgeschlagen, Fehlercode 4196.
    ( ii) kryptographische Prüfung des (EndEntity-)CV-Zertifikats fehlgeschlagen, Fehlercode 4196.
    ( iii) zeitliche Gültigkeit eines der CV-Zertifikate ist abgelaufen, Fehlercode 4196.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 270: TAB_KON_819 Fehlercodes TUC_KON_042 „CV-Zertifikat prüfen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4196
    Technical
    Error
    Fehler bei der CV-Zertifikatsprüfung
    4228
    Technical
    Error
    das benötigte Cross-CV-Zertifikat ist nicht vorhanden
    <=

    4.1.9.4.3 TUC_KON_034 „Zertifikatsinformationen extrahieren“

    TIP1-A_4697

    Der Konnektor MUSS den technischen Use Case TUC_KON_034 „Zertifikatsinformationen extrahieren” umsetzen.

    Tabelle 271: TAB_KON_770 TUC_KON_034 „Zertifikatsinformationen extrahieren“

    Element
    Beschreibung
    Name
    TUC_KON_034 „Zertifikatsinformationen extrahieren“
    Beschreibung
    Dieser TUC beschreibt die Extraktion der fachlich zentralen Informationen aus bestimmten Zertifikaten einer gesteckten Karte eines Mandanten.
    Auslöser
    • Aufruf durch ein Fachmodul oder eine Basisanwendung des Konnektors
    Vorbedingungen
    Keine
    Eingangsdaten
    • cardSession – optional/verpflichtend für den Zugriff auf eGK, HBA, SM-B oder gSMC-KT
    • checkSMCK [Boolean] – optional/verpflichtend für gSMC-K;
      (Referenz auf eine/die gSMC-K, alternativ zu cardSession)
    • qes [Boolean] - optional; default: false
      (Angabe, ob die QES-Identität oder die nonQES-Identität der Karte interessiert)
    • crypt - optional; default = RSA
      (kryptographischer Algorithmus, für welchen das Zertifikat ermittelt wird;
      Wertebereich: ECC, RSA)
    Komponenten
    Konnektor
    Ausgangsdaten
    • certType [C.CH.AUT | C.HP.AUT | C.HCI.AUT | C.HP.QES]
      (Zertifikatstyp)
    • certInfo
      (Zertifikatsinformationen, bestehend aus SerialNumber, Issuer, Subject, Rollen, registrationNumber und ggf. id-etsi-qcs-QcCompliance, siehe Standardablauf)
    • qcStatments – optional/nur wenn certType =  C.HP.QES
      (QCStatements)
    Nachbedingungen
    Keine
    Standardablauf
    1. Je nach Kartentyp wird aus der Karte das passende Zertifikat über TUC_KON_216 "LeseZertifikat" {selektiertes Zertifikat} ausgelesen. Das Zertifikatsobjekt (fileIdentifier und folder)/Zertifikatsbezeichnung wird für die jeweilige Karte unter Berücksichtigung des kryptographischen Verfahrens crypt gemäß TAB_KON_858 bzw. TAB_KON_856  ermittelt.
      1. Bei qes = false:
        1. Für die eGK: C.CH.AUT
        2. Für den HBAx: C.HP.AUT
        3. Für SM-B: C.HCI.AUT
        4. Für gSMC-K: C.NK.VPN
      2. Bei qes = true:
        1. Für den HBAx: C.HP.QES
    2. Die Zertifikatsbezeichnung aus Schritt 1 („C.XXX.YYY.ZZZZ“) wird als Ausgangsdatum „certType“ zurückgegeben.
    3. Zusätzlich werden aus dem Zertifikat folgende Informationen
      extrahiert und zurückgegeben:
      1. X509SerialNumber
      2. Issuer (DistinguishedName) nach RFC 2253
      3. Subject (DistinguishedName) nach RFC 2253
      4. Aus der Extension Admission:
        1. eine Liste von Rollen durch Aufruf von TUC_PKI_009 „Rollenermittlung”
        2. registrationNumber (=Telematik-ID; falls vorhanden)
      5. id-etsi-qcs-QcCompliance (0.4.0.1862.1.1) in QCStatements, falls vorhanden
      6. Restriction, falls vorhanden
      7. validity
    Varianten/Alternativen
    Keine
    Fehlerfälle
    (1) Wenn im Aufrufkontext (also erreichbar durch den Mandanten) zum angegebenen CardHandle keine Karte gefunden werden kann, bricht der TUC mit Fehlercode 4146 ab.
    (1b) Ist bei Angabe von QES=true auf der Karte keine QES-Identität zu finden, bricht der TUC mit Fehlercode 4147 ab. Für die Kombination QES=true mit einer eGK bricht der TUC mit Fehlercode 4148 ab (QES-Zertifikate der eGK werden noch nicht unterstützt).
    (1) Für eGK, HBA, SM-B gilt: Wenn crypt=ECC und Karte vom Typ <G2.1, bricht der TUC mit Warnung 4257 ab.
    (1) Für gSMC-K gilt: Wenn crypt=ECC und TUC_KON_216 Warnung 4256 liefert, bricht der TUC mit Warnung 4257 ab.
    (1) Wenn aus anderen Gründen die Extraktion der Zertifikatsinformationen fehlschlägt, bricht der TUC mit Fehlercode 4148 ab.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 272: TAB_KON_602 Fehlercodes TUC_KON_034 „Zertifikatsinformationen extrahieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4146
    Technical
    Error
    Kartenhandle existiert nicht
    4147
    Technical
    Error
    Zertifikat nicht vorhanden (z. B. kein QES-Zertifikat in SM-B)
    4148
    Technical
    Error
    Fehler beim Extrahieren von Zertifikatsinformationen
    4257 Technical Warning ECC-Zertifikate nicht vorhanden auf Karte: <cardHandle>

    <=

    4.1.9.5 Operationen an der Außenschnittstelle

    TIP1-A_4698-03

    Der Konnektor MUSS Clientsystemen eine Basisanwendung Zertifikatsdienst zur Verfügung stellen

    Tabelle 273: TAB_KON_771 Basisanwendung Zertifikatsdienst

    Name
    CertificateService
    Version (KDV)
    6.0.0 (WSDL-Version), 6.0.1 (XSD-Version)
    6.0.1 (WSDL-Version), 6.0.2 (XSD-Version)

    Namensraum
    Siehe GitHub
    Namensraum-Kürzel
    CERT für Schema und CERTW für WSDL
    Operationen
    Name
    Kurzbeschreibung
    ReadCardCertificate
    Zertifikat von einer Karte lesen
    CheckCertificateExpiration
    Ablaufdatum von Zertifikaten erfragen
    VerifyCertificate
    Prüfung des Status eines Zertifikats
    WSDL
    CertificateService.wsdl (WSDL-Verion 6.0.0)
    CertificateService_v6_0_1.wsdl

    Schema
    CertificateService.xsd (XSD-Version 6.0.1)
    CertificateService_v6_0_2.xsd


    <=

    4.1.9.5.1 CheckCertificateExpiration

    TIP1-A_4699-03

    Die Basisanwendung Zertifikatsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation CheckCertificateExpiration anbieten.

    Tabelle 274: TAB_KON_676 Operation CheckCertificateExpiration

    Name
    CheckCertificateExpiration
    Beschreibung
    Gibt das Datum des Ablaufs eines bestimmten Zertifikats oder gesammelt des Zertifikats der gSMC-K, der gSMC-KT's sowie aller gesteckten HBAx und SM-B des Mandanten zurück.
    Aufruf-parameter


    Name
    Beschreibung
    CardHandle
    Optional. Identifiziert die Karte, deren Zertifikate geprüft werden sollen. Wird der Parameter nicht angegeben, so werden alle für den Konnektor erreichbaren Karten (inkl. gSMC-K und aller gSMC-KT's), die zum Mandanten passen, berücksichtigt.
    Die Operation CheckCertificateExpiration DARF das Lesen von Zertifikaten der eGK NICHT unterstützen.
    Context
    MandantId, CsId, WorkplaceId verpflichtend; UserId optional
    Crypt Optional; Default: RSA 
    Gibt den kryptopraphischen Algorithmus vor, für den das Zertifikat ermittelt werden soll.
    Wertebereich: RSA, ECC
    • RSA: Zertifikat für RSA-2048
    • ECC: Zertifikat für ECC-256
    Rückgabe


    Status
    Enthält den Ausführungsstatus der Operation.
    CertificateExpiration
    Eine Liste von Tupeln aus (CtID, CardHandle, ICCSN, subject.CommonName, serialNumber, validity) der Zertifikate der Karten.
    Für die gSMC-K soll in CertificateExpiration/CtID und CertificateExpiration/CardHandle jeweils ein Leerstring zurückgegeben werden.
    Vorbe-dingungen
    Keine
    Nachbe-dingungen
    Keine
    Der Ablauf der Operation CheckCertificateExpiration ist in Tabelle TAB_KON_677 beschrieben:

    Tabelle 275: TAB_KON_677 Ablauf CheckCertificateExpiration

    Nr.
    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung
    1.


    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab. Wird die Operation für einen nicht unterstützten Kartentypen aufgerufen, so bricht die Operation mit Fehler 4058 ab.
    2.


    TUC_KON_000 „Prüfe Zugriffsberechtigung“
    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientSystemId = $context.clientsystemId;
        workplaceId  = $context.workplaceId;
        userId = $context.userId;
        cardHandle = $cardHandle
        allWorkplaces=true
    }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3.


    enumerateCardHandles
    Wenn der Parameter CardHandle übergeben wurde, wird dieser als einziges Element in eine Liste gepackt.
    Wenn der Parameter CardHandle leer war, wird eine Liste der CardHandles aller für den Konnektor erreichbaren Karten (inkl. gSMC-K und gSMC-KT's), die zum Mandanten passen, erstellt.
    Für jedes CardHandle der in Schritt 3 erzeugten Liste werden folgende Schritte ausgeführt, für die gSMC-Ks die Schritte 5 und 6:
    Falls Schritt 5 der TUC_KON_033 die Warnung 4257 zurückgibt, wird Schritt 6 nicht ausgeführt und die Schritte für das CardHandle der in Schritt 3 erzeugten Liste weiter ausgeführt. Die Warnung 4257 wird über alle CardHandle akkumuliert und <komma-separierte List von cardHandle> für den Fehlertext erzeugt.
    4.


    TUC_KON_026 „Liefere CardSession“
    Ermittle CardSession über TUC_KON_026 {
        mandatId =MandantId;
        clientSystemId = ClientSystemId;
        cardHandle = CardHandle;
        userId = UserId }
    5.


    TUC_KON_033 „Zertifikatsablauf prüfen“
    Das Gültigkeitsdatum des Zertifikats wird geprüft mit TUC_KON_033 {
        cardSession;
        doInformClients = false;
        Crypt;
    }
    bzw. TUC_KON_033 {
        checkSMCK = true;
        doInformClients = false;
        Crypt;

    6.


    TUC_KON_034 „Zertifikatsinformationen extrahieren”
    Beim Aufruf des TUC_KON_034 ist der Parameter qes = false zu setzen.
    Aus den jeweiligen Rückgabewerten entsteht eine Liste aus Tupeln (CtID, CardHandle, ICCSN, subject.CommonName, serialNumber, validity). Diese wird von der Operation zurückgegeben.

    Tabelle 276: TAB_KON_603 Fehlercodes „CheckCertificateExpiration“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4058
    Security
    Error
    Aufruf nicht zulässig
    4257 Technical Warning ECC-Zertifikate nicht vorhanden auf Karte: <komma-separierte List von cardHandle>
    <=

    4.1.9.5.2 ReadCardCertificate

    TIP1-A_4700

    Die Basisanwendung Zertifikatsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation ReadCardCertificate wie in Tabelle TAB_KON_678 Operation ReadCardCertificate beschrieben anbieten.

    Tabelle 277: TAB_KON_678 Operation ReadCardCertificate

    Name
    ReadCardCertificate
    Beschreibung
    Liest X.509-Zertifikate von einer Karte.
    Aufruf-parameter




    Name
    Beschreibung
    CardHandle
    Gibt die Karte an, von der das Zertifikat gelesen werden soll.
    Es können Zertifikate von HBAx (HBA, HBA-VK), SM-B ausgelesen werden.
    Die Operation ReadCardCertificate DARF das Lesen von Zertifikaten der eGK NICHT unterstützen.
    Context
    Aufrufkontext (Mandant)
    CertRefList
    Gibt an, welche(s) Zertifikat(e) gelesen werden soll. Mögliche Werte für CertRef sind:

    C.AUT, C.ENC, C.SIG, C.QES
    Crypt Optional; Default: RSA 
    Gibt den kryptographischen Algorithmus vor, für den das Zertifikat ermittelt werden soll.
    Wertebereich: RSA, ECC
    • RSA: Zertifikat für RSA-2048
    • ECC: Zertifikat für ECC-256
    Rückgabe




    Status
    Enthält den Ausführungsstatus der Operation.
    CertRef
    Dieses Element beinhaltet die Referenz des Zertifikats, welches bei der Anfrage übergeben wurde.
    X509Data
    Inhalt des über die CertRef referenzierten Zertifikats. Ist das referenzierte Zertifikat nicht vorhanden, so wird dieses Element nicht vom Konnektor gefüllt.

    X509Issuer
    Name

    Enthält den Issuer-Name des Zertifikats. Bezüglich des Encodings sind die in [XMLDSig#4.4.4.4.1] angegebenen Regeln zu beachten (Escaping von Sonderzeichen etc.)

    X509Serial
    Number

    Enthält die serialNumber des Zertifikats.

    X509Subject
    Name

    Enthält das Feld subject.CommonName. Bezüglich des Encodings sind die in [XML DSig#4.4.4.4.1] angegebenen Regeln zu beachten (Escaping von Sonderzeichen etc.)


    X509
    Certificate

    Enthält das base64-codierte Zertifikat, dessen Binärstruktur wiederum ASN.1-codiert (gemäß [COMMON_PKI]) vorliegt.
    Vorbe-dingungen
    Keine
    Nachbe-dingungen
    Keine

    Der Ablauf der Operation ReadCardCertificate ist in Tabelle TAB_KON_679 Ablauf ReadCardCertificate beschrieben:

    Tabelle 278: TAB_KON_679 Ablauf ReadCardCertificate

    Nr.
    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung
    1.
    checkArguments
    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    Wurde als Zielkarte eine eGK adressiert, wird Fehlercode 4090 zurückgeliefert.
    2.


    TUC_KON_000 „Prüfe Zugriffs- berechtigung“
    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {
        mandantId = $context.mandantId;
        clientsystemId = $context.clientsystemId;
        workplaceId  = $context.workplaceId;
        userId = $context.userId;
        cardHandle = $cardHandle
    }
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3.


    TUC_KON_026 „Liefere CardSession“
    Ermittle CardSession über TUC_KON_026 {
        mandatId =$context.mandantId;
        clientsystemId  = $context.clientsystemId;
        cardHandle = $context.cardHandle;
        userId = $context.userId }
    4.


    getEF
    Für jedes Paar von CertRef und CardHandle wird in Abhängigkeit des Parameters Crypt gemäß Tabelle TAB_KON_858 das zu lesende File (EF) bestimmt:
    Ist die übergebene Zertifikatsreferenz ungültig, wird Fehlercode 4149 zurückgegeben.
    Das Lesen von Zertifikaten der eGK ist aus Sicherheitsgründen für Clientsysteme nicht zulässig.
       TUC_KON_216 „LeseZertifikat“
    Für jedes Paar von CardHandle und EF wird nun durch Aufruf von TUC_KON_216 „LeseZertifikat“ das Zertifikat ausgelesen.
    Falls TUC_KON_216 die Warnung 4256 zurückgibt, wird die Operation abgebrochen und Fehler 4258 zurückgegeben.
    6.


    Zertifikatsattribute extrahieren
    Aus jedem Zertifikat werden die zu liefernden Attribute extrahiert. Die Ergebnisstruktur wird mit den erhaltenen Rückgabewerten gefüllt.


    Tabelle 279: TAB_KON_604 Fehlercodes „ReadCardCertificate“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4149
    Technical
    Error
    Ungültige Zertifikatsreferenz
    4090
    Security
    Error
    Zugriff auf eGK nicht gestattet
    4258 Technical Error ECC-Zertifikate nicht vorhanden auf Karte: <cardHandle>

    <=

    4.1.9.5.3 VerifyCertificate

    TIP1-A_5449

    Die Basisanwendung Zertifikatsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation VerifyCertificate wie in Tabelle TAB_KON_795 Operation VerifyCertificate beschrieben anbieten.

    Tabelle 280: TAB_KON_795 Operation VerifyCertificate

    Name

    VerifyCertificate

    Beschreibung

    Prüft den Status eines Zertifikats.

    Aufruf-parameter


    Name

    Beschreibung

    CCTX:Context

    Aufrufkontext (Mandant)

    CERTCMN:
    X509Certificate

    Zu prüfendes Zertifikat (base64 kodiert), wie in Response zur Operation ReadCardCertificate enthalten.

    CERT:
    VerificationTime

    Der für die Prüfung zu verwendende Referenzzeitpunkt. Falls der Parameter nicht angegeben ist, wird als Referenzzeitpunkt die Systemzeit verwendet.

    Rückgabe


    CONN:Status

    Enthält den Ausführungsstatus der Operation.

    CERT:
    Verification
    Status

    Enthält eines der drei möglichen Prüfungsergebnisse in CERT:VerificationResult

      • VALID

      • INCONCLUSIVE

      • INVALID

    sowie weiter Details zu den Zuständen „INCONCLUSIVE“ und „INVALID“ in GERROR:Error.

    CERT:RoleList

    OIDs der im Zertifikat gespeicherten Rollen.

    Vorbe-dingungen

    Keine

    Nachbe-dingungen

    Keine

    Der Ablauf der Operation VerifyCertificate ist in Tabelle TAB_KON_797 Ablauf VerifyCertificate beschrieben:

    Tabelle 281: TAB_KON_797 Ablauf VerifyCertificate

    Nr.

    Aufruf Technischer Use Case oder Interne Operation

    Beschreibung

    1.

    checkArguments

    Die übergebenen Werte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.

    2.


    TUC_KON_037 „Zertifikat prüfen“

    Die Zertifikatsprüfung erfolgt durch Aufruf von TUC_KON_037. Als Parameter des TUC-Aufrufs gilt für Zertifikate aus CERT_IMPORTED_CA_LIST: {
    certificate = CERTCMN:X509Certificate
    qualifiedCheck = not_required;
    baseTime = CERT:VerificationTime;
    offlineAllowNoCheck = true;
    policyList= keine Einschränkung;
    intendedKeyUsage=empty;
    intendedExtendedKeyUsage=empty;
    gracePeriod = empty;
    validationMode = NONE;
    ocspResponses (OCSP-Response/Liste von OCSP-
            Responses = empty }
    für alle anderen Zertifikate gilt: {
    certifiacate = CERTCMN:X509Certificate
    qualifiedCheck =if_QC_present;
    baseTime = CERT:VerificationTime;
    offlineAllowNoCheck = true;
    policyList = alle zugelassenen Zertifikatstyp-OIDs;
    intendedKeyUsage = empty;
    intendedExtendedKeyUsage = empty;
    gracePeriod = empty;
    validationMode = OCSP;
    ocspResponses = empty}.

    3.



    Wenn der Prüfprozess fehlerhaft war und nicht zu einem Ergebnis im Sinne eines VerificationResult führt, wird eine FaultMessage erzeugt.
    War der Prüfprozess erfolgreich, wird eine VerifyCertificateResponse mit CONN:Status/CONN:Result=OK, dem VerificationStatus (als Ergebnis der Zertifikatsprüfung) und den ermittelten Rollen-OIDs erzeugt. Ein Prüfergebnis „INCONCLUSIVE“ bzw. „INVALID“ wird in CERT:VerificationStatus/GERROR:Error mit den zugehörigen Fehlermeldungen detailliert (in diesem Fall kann CONN:Status/CONN:Result=OK oder CONN:Status/CONN:Result=Warning gesetzt sein).

    Tabelle 282: TAB_KON_800 Fehlercodes „VerifyCertificate“

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:

    4000

    Technical

    Error

    Syntaxfehler


    ​​

    <=

    4.1.9.6 Betriebsaspekte
    4.1.9.6.1 TUC_KON_035 „Zertifikatsdienst initialisieren“

    TIP1-A_4701

    In der Bootup-Phase MUSS der Konnektor den Zertifikatsdienst durch Aufruf des TUC_KON_035 „Zertifikatsdienst initialisieren“ initialisieren.

    Tabelle 283: TAB_KON_772 TUC_KON_035 „Zertifikatsdienst initialisieren“

    Element
    Beschreibung
    Name
    TUC_KON_035 „Zertifikatsdienst initialisieren“
    Beschreibung
    Der TUC beschreibt den gesamten Ablauf der Initialisierung des TrustStore im Rahmen der betrieblichen Prozesse: Prüfung der Aktualität, Integrität und Authentizität der Einträge im TrustStore.
    Auslöser
    •  Bootup des Konnektors
    Vorbedingungen
    keine
    Eingangsdaten
    keine
    Komponenten
    Konnektor
    Ausgangsdaten
    •      Status der Initialisierung des TrustStore
    Nachbedingungen
    Keine
    Standardablauf
    Für den übergebenen Status der Initialisierung des TrustStore werden folgende Schritte durchgeführt:
    1. Durch eine DNS-Anfrage an den DNS-Forwarder zur Auflösung der SRV-RR mit dem Bezeichner "_ocsp._tcp.<DOMAIN_SRVZONE_TI>„ erhält der Konnektor Adressen des http-Forwarders des VPN-Zugangsdienststandortes.
    2. Falls in den letzten 24 Stunden keine Aktualisierung der TSL und CRL im Truststore stattgefunden hat, aktualisiert der Konnektor die TSL durch den Aufruf von TUC_KON_032 „TSL aktualisieren“ und die CRL durch den Aufruf von TUC_KON_040 „CRL aktualisieren“.
    3. Falls im Zeitraum von CERT_BNETZA_VL_UPDATE_INTERVAL keine Aktualisierung der BNetzA VL stattgefunden hat, aktualisiert der Konnektor die BNetzA VL durch den Aufruf von TUC_KON_031 „BNetzA-VL aktualisieren“.
    4. Der Konnektor prüft die Gültigkeitsdauer der Zertifikate aller gesteckten Karten (inkl. gSMC-K) mittels Aufruf von:
      für gSMC-K
      TUC_KON_033{checkSMCK; doInformClients=Ja; crypt = ECC}
      TUC_KON_033{checkSMCK; doInformClients=Ja; crypt = RSA}
      für jede gesteckte G2.0 Karte
      TUC_KON_033{cardSession; doInformClients=Ja; crypt = RSA}
      für jede gesteckte ab G2.1 Karte
      TUC_KON_033{cardSession; doInformClients=Ja; crypt = ECC}
      TUC_KON_033{cardSession; doInformClients=Ja; crypt = RSA}
    5. Der Konnektor liest von der gSMC-K den öffentlichen Schlüssel des CVC-Root-Zertifikats und speichert diesen im TrustStore [gemSpec_gSMC-K_ObjSys#5.3.10].
    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    Keine
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige
    Diagramme

    Keine

    Tabelle 284: TAB_KON_605 Fehlercodes TUC_KON_035 „Zertifikatsdienst initialisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

    <=

    TIP1-A_4702-04

    Der Administrator MUSS die in TAB_KON_606 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_733 aufgelisteten Parameter ausschließlich einsehen können.

    Tabelle 285: TAB_KON_606 Konfiguration des Zertifikatsdienstes

    ReferenzID
    Belegung
    Bedeutung
    CERT_TSL_DEFAULT_
    GRACE_PERIOD_DAYS

    X Tage
    Default Grace Period TSL in Tagen
    Gibt an, wie viele Tage der Konnektor mit einer zeitlich abgelaufenen TSL weiter betrieben werden kann.
    Der Wert MUSS zwischen 1 und 30 Tagen liegen.
    Default-Wert = 30 Tage
    Hinweis: Vor dem zeitlichen Ablauf einer TSL wird mit ausreichendem Vorlauf eine neue TSL verteilt. Sollte die TSL dennoch ablaufen und der Konfigurationswert überschritten werden, kann eine neue TSL immer noch lokal geladen werden (TIP1-A_4705 „TSL manuell importieren“).
    CERT_OCSP_DEFAULT_
    GRACE_PERIOD_
    NONQES

    X Minuten
    Default Grace Period OCSP für nonQES in Minuten.
    Der Wert MUSS zwischen 0 und 20 Minuten liegen.
    Default-Wert = 10 Minuten
    CERT_OCSP_TIMEOUT_
    NONQES

    X Sekunden
    Timeout für OCSP-Abfragen bei der Prüfung von nonQES-Zertifikaten.
    Der Wert MUSS zwischen 1 und 120 Sekunden liegen.
    Default-Wert = 10 Sekunden
    CERT_OCSP_TIMEOUT_
    QES

    X Sekunden
    Timeout für OCSP-Abfragen bei der Prüfung von QES-Zertifikaten.
    Der Wert muss zwischen 1 und 120 Sekunden liegen.
    Default-Wert = 10 Sekunden
    CERT_EXPIRATION_
    WARN_DAYS

    X Tag(e)
    Warnung X Tage vor Ablauf von Zertifikaten im Managementinterface und per Ereignis.
    Der Wert muss zwischen 0 und 180 Tagen (0=keine Warnung) liegen.
    Default-Wert = 90 Tage
    CERT_EXPIRATION_
    CARD_CHECK_DAYS

    X Tag(e)
    Alle X Tage wird der Ablauf aller gesteckten Karten überprüft. Der Wert muss zwischen 0 und 365 liegen (0=kein Check).
    Default-Wert = 1 Tag
    CERT_IMPORTED_
    CA_LIST

    Liste von manuell importierten CA-Zertifikaten
    Der Administrator MUSS CA-Zertifikate importieren, anzeigen und löschen können. Der Konnektor DARF CA-Zertifikate zur Ableitung von QES-Zertifikaten NICHT importieren.
    Default-Wert = leere Liste
    CERT_BNETZA_VL_
    UPDATE_INTERVAL

    X Stunden
    Intervall, in dem die BNetzA VL auf Aktualität geprüft  werden muss. Der Wert MUSS zwischen 1 Stunde und 168 Stunden (7 Tage) liegen.
    Default-Wert = 24 Stunden
    CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU 1 URI Konfigurierbare Backup Adresse der TSL im Internet
    CERT_TSL_IP_ADDRESS_INTERNET_BU 1 URI
    Konfigurierbare Backup Adresse der TSL im Internet (enthält IP-Adresse des Hosts statt FQDN).
    Wird verwendet, falls Auflösen der FQDN mittels DNS bei CERT_TSL_DOWNLOAD_ADDRESS_INTERNET_BU
    fehlschlägt.

    Tabelle 286: TAB_KON_733 Einsehbare Konfigurationsparameter des Zertifikatsdienstes

    ReferenzID
    Belegung
    Bedeutung
    CERT_CRL_DOWNLOAD_ADDRESS
    2 URIs
    Download-Adressen für die CRL
    CERT_OCSP_FORWARDER_ADDRESS
    2 FQDNs
    Adressen der OCSP-Forwarder (HTTPS-Proxy) beim Zugangsdienstprovider
    Der Administrator muss in geeigneter Weise einen Test auslösen können, ob einer der Server per ICMP-Echo (ping) erreichbar ist und ob ein (beliebiger) OCSP-Request zu einer erhaltenen OCSP-Antwort führt.
    CERT_OCSP_FORWARDER_PORT
    TCP-Port
    TCP-Port des OCSP-Forwarders (HTTPS-Proxy) beim Zugangsdienstprovider
    CERT_TSL_DOWNLOAD_ADDRESS_INTERNET 1 URI Adresse der TSL im Internet gemäß gemSpec_TSL
    CERT_TSL_IP_ADDRESS_INTERNET 1 URI
    Adresse der TSL im Internet gemäß gemSpec_TSL (enthält IP-Adresse des Hosts statt FQDN).
    Wird verwendet, falls Auflösen der FQDN mittels DNS bei CERT_TSL_DOWNLOAD_ADDRESS_INTERNET
    fehlschlägt.

    <=

    TIP1-A_4703-01

    Das Managementinterface des Konnektors MUSS einem authentisierten Administrator die Anzeige des Status des Vertrauensraums in Form folgender Daten anbieten: Sequenznummer der aktuellen TSL, StatusStartingTime (des TSPService (TSL-Signer-CA-Dienst) zum aktuell gültigen, aktiven TI-Vertrauensanker), NextUpdate, Gültigkeit der TSL, Typ der TSL (RSA oder ECC-RSA)) sowie optional für den Administrator einsehbar der Fingerprint des TSL-Signer-Zertifikats. <=

    Der Typ der TSL liefert dem Administrator die Information, ob es sich um eine TSL handelt, die den TI-Vertrauensraum ausschließlich für Zertifikate mit kryptographischen Verfahren nach RSA-2048 (TSL(RSA)) oder für Zertifikate mit kryptographischen Verfahren nach RSA-2048 und ECC-256 (TSL(ECC-RSA)) bereitstellt. Die Information kann aus der Signatur der TSL ermittelt werden.

    TIP1-A_6733

    Das Managementinterface des Konnektors MUSS einem authentisierten Administrator die Anzeige des Status der BNetzA-VL in Form folgender Daten anbieten: Sequenznummer, NextUpdate, Gültigkeitsstatus und Zeitpunkt der letzten Prüfung der Aktualität durch TUC_KON_031.
    <=

    TIP1-A_4704

    Der Administrator MUSS einen Prüflauf auf den innerhalb von CERT_EXPIRATION_WARN_DAYS Tagen bevorstehenden Ablauf von Zertifikaten aller für den Konnektor erreichbaren Karten (inkl. gSMC-K) an zentraler Stelle in der Managementschnittstelle auslösen können und das Ergebnis angezeigt bekommen.
    Der Konnektor MUSS die Gültigkeitsdauer der Zertifikate aller gesteckten Karten (inkl. gSMC-K) prüfen mittels Aufruf von:
    für gSMC-K
    TUC_KON_033{checkSMCK; doInformClients=Nein; crypt = ECC}
    TUC_KON_033{checkSMCK; doInformClients=Nein; crypt = RSA}
    für jede gesteckte G2.0 Karte außer gSMC-K
    TUC_KON_033{cardSession; doInformClients=Nein; crypt = RSA}
    für jede gesteckte ab G2.1 Karte außer gSMC-K
    TUC_KON_033{cardSession; doInformClients=Nein; crypt = ECC}
    TUC_KON_033{cardSession; doInformClients=Nein; crypt = RSA} <=

    A_18931

    Der Konnektor MUSS dem Administrator die X.509-Zertifikate der verbauten gSMC-Ks  gemäß TIP1-A_4506 anzeigen. Aus der Anzeige MUSS der Personalisierungs-Status der X.509-Zertifikate ersichtlich sein (dual RSA- und ECC-personalisiert oder nur RSA-personalisiert).
    <=

    TIP1-A_4705

    Der Konnektor MUSS es dem Administrator ermöglichen, eine TSL manuell von lokaler Datenquelle einzuspielen. Dabei MUSS der Konnektor TUC_KON_032{TSL-Datei} mit der manuell importierten TSL aufrufen.
    Der Konnektor MUSS den manuellen Import einer TSL auch ermöglichen, wenn er sich im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period befindet.
    Der Konnektor MUSS den manuellen Import einer zeitlich abgelaufenen TSL zulassen. 
    <=

    Auch im Fall des automatischen Imports der TSL muss dies im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period unterstützt werden.

    A_20536

    Der Konnektor MUSS den automatischen Import einer TSL auch ermöglichen, wenn er sich im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period befindet.  <=

    A_20748

    Falls der Konnektor im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period ist, und falls onlineMode = ENABLED ist, MUSS der Konnektor periodisch und in der BootUp Phase die TSL aktualisieren. <=

    TIP1-A_6728

    Der Konnektor MUSS es dem Administrator ermöglichen, die BNetzA-VL manuell von lokaler Datenquelle einzuspielen. Dabei MUSS der Konnektor TUC_KON_031{BNetzA-VL-Datei} mit der manuell importierten BNetzA-VL-Datei aufrufen.
    <=

    TIP1-A_4706

    Der Konnektor SOLL es dem Administrator ermöglichen, eine CRL manuell von einer lokalen Datenquelle einzuspielen. In dem Fall MUSS der Konnektor TUC_KON_040{CRL-Datei} mit der manuell importierten CRL aufrufen. <=

    Für die ECC-Migration ist es notwendig den ECC-RSA-Vertrauensraum zu etablieren. Dies erfolgt durch das Einspielen eines TSL-Signer-CA Cross-Zertifikats und das neue TSL-Signer-CA-Zertifikat, wodurch der ECC-Vertrauensanker im Konnektor im sicheren Datenspeicher gespeichert wird. Die Prüfung des Cross-Zertifikats erfolgt durch A_17821 - Wechsel des Vertrauensraumes mittels Cross-Zertifikaten (ECC-Migration). Danach kann die TSL(ECC-RSA) importiert werden. Das Ergebnis ist ein etablierter TI-Vertrauensraum für ECC und RSA.
    Konnektoren müssen den ECC-Vertrauensraum automatisiert und im Rahmen des Upgrades auf PTV4 etablieren. Manuelle Schritte durch den Administrator sind für den Regelfall zu vermeiden und sollten nur im Fehlerfall nötig werden. Als Fallback-Lösung muss das manuelle Verfahren dennoch unterstützt werden.

    A_20469-02

    In der BootUp-Phase MUSS ein Konnektor, der den RSA-Vertrauensraum (RSA) verwendet, überprüfen, ob die TSL(ECC-RSA) und die entsprechenden TSL-Signer-CA Cross-Zertifikate sowie TSL-Signer-CA-Zertifikate verfügbar sind und MUSS sie im positiven Fall automatisiert herunterladen, nach erfolgreicher Prüfung verwenden und dadurch den ECC-Vertrauensraum (ECC-RSA) etablieren.
    Der Konnektor MUSS hierzu die Downloadpunkte, die mit A_17680-01 in [gemSpec_TSL#6.3.1.2] definiert sind, verwenden.
    Falls beim Wechsel auf den  ECC-RSA Vertrauensraum ein Fehler auftritt, MUSS der Konnektor weiterhin den RSA-Vertrauensraum (RSA) verwenden. <=

    A_20508-01

    Der Konnektor MUSS alle Schritte, die er zur Etablierung des ECC-RSA-Vertrauensraums durchläuft, im Systemprotokoll des Konnektors mit dem Log-Level "Warning" protokollieren. <=

    A_17345

    Der Konnektor MUSS es dem Administrator ermöglichen, ein TSL-Signer-CA Cross-Zertifikat und das TSL-Signer-CA-Zertifikat für den neuen TI-Vertrauensanker manuell von lokaler Datenquelle einzuspielen.    <=

    A_17837-01

    Um auf Basis des bereits etablierten Vertrauensankers (RSA) in den Vertrauensraum (ECC-RSA) zu wechseln MUSS der Konnektor bei der Initialisierung des neuen Vertrauensankers (ECC-RSA) Cross-Zertifikate verwenden. Das Ergebnis ist ein neuer etablierter TI-Vertrauensanker (ECC-RSA). <=

    A_17548-01

    Der Konnektor MUSS den neuen TI-Vertrauensanker im sicheren Datenspeicher speichern. <=

    A_17549-01

    Der Konnektor MUSS den Import des TSL-Signer-CA Cross-Zertifikats auch ermöglichen, wenn er sich im kritischen Betriebszustand EC_TSL_Out_Of_Date_Beyond_Grace_Period befindet.  <=

    A_17550-01

    Falls der Import des TSL-Signer-CA Cross-Zertifikats nicht erfolgreich durchgeführt werden konnte, MUSS der Konnektor den Vorgang abbrechen und einen Fehler gemäß TAB_KON_857 dem Administrator zur Anzeige bringen und protokollieren.

    Tabelle 287: TAB_KON_857 - Fehlercodes beim Import des Cross-Zertifikats für TI-Vertrauensanker ECC

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4255
    Security
    Error
    Fehler beim Import des TSL-Signer-CA Cross-Zertifikats
    <=

    TIP1-A_5700

    Beim Auftreten des Events NETWORK/VPN_TI/UP MUSS der Konnektor über DNS die Adressen des http-Forwarders des VPN-Zugangsdienststandortes ermitteln (SRV-RR mit Bezeichner "_ocsp._tcp.<DOMAIN_SRVZONE_TI>).
    <=

    A_21158

    Der Konnektor MUSS mindestens 20 CV-Crosszertifikate verwalten und verarbeiten können. <=

    4.1.10 Protokollierungsdienst

    Der Protokollierungsdienst protokolliert system- und sicherheitsrelevante Ereignisse, sowie Ereignisse im Kontext der Performancemessung (siehe [gemSpec_Perf#4.1.2), innerhalb des Konnektors. Auch Ereignisse von Fachmodulen können protokolliert werden. Im Sicherheitsprotokoll werden alle Ereignisse eingetragen, die Auswirkungen auf Sicherheitsmerkmale des Konnektors haben können (Änderungen an der Firewall-Konfiguration, Authentisierungsfehler etc.). Ereignisse im Kontext der Performancemessung innerhalb des Konnektors werden in das Konnektor-Performanceprotokoll geschrieben. Ereignisse im Kontext der Performancemessung von Fachmodulen werden in das Fachmodul-Performanceprotokoll geschrieben. Alle anderen Ereignisse werden in das Systemprotokoll oder die Fachmodulprotokolle geschrieben (grundsätzlich trifft die Entscheidung über den zu verwendenden Protokollspeicher der Aufrufer des Protokolldienstes).

    Die Protokolle werden persistiert.

    Hinweis:
    Ereignisse im Protokollierungsdienst adressieren nicht nur zu protokollierende Events im Sinne des Systeminformationsdienstes sondern alles, was zu einem Protokolleintrag führen soll (z.B. Fehler, Informationen zu Ablauf, Debug, Performance).

    Innerhalb des Protokollierungsdienstes werden folgende Präfixe für Bezeichner verwendet:

    4.1.10.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4708

    Der Konnektor MUSS einen Protokollierungsdienst anbieten. Dabei MUSS der Konnektor zwischen System- und Sicherheitsprotokoll, sowie Fachmodulprotokollen unterscheiden. Je Fachmodul MUSS ein getrenntes Protokoll vorhanden sein.

    Die Protokolleinträge MÜSSEN durch den Konnektor lokal persistiert werden.

    <=

    TIP1-A_5654

    Der Konnektor MUSS herstellerspezifische Fehler, die Auswirkungen auf Sicherheitsmerkmale des Konnektors haben, in das Sicherheitsprotokoll schreiben.

    <=

    TIP1-A_4709

    Der Konnektor MUSS sicherstellen, dass Einträge in das Sicherheitsprotokoll nicht von außen und nicht durch den Administrator verändert und gelöscht werden können.

    <=

    TIP1-A_4710

    Der Konnektor DARF medizinische Daten NICHT in die Protokolldateien schreiben.
    Personenbezogene Daten DÜRFEN NICHT in Protokolleinträgen gespeichert werden.
    KVNR, ICCSN und CardHolderName MÜSSEN als personenbezogene Daten behandelt werden.
    Die ICCSN DARF Im Fehlerfall durch Fachmodule in Protokolleinträgen gespeichert werden. Die ICCSN DARF NICHT im Sicherheitsprotokoll gespeichert werden.
    <=

    TIP1-A_6479

    Der Konnektor DARF vertrauliche Daten NICHT in die Protokolldateien schreiben.

    <=

    TIP1-A_4711

    Der Konnektor MUSS über eine Speichergröße für Protokolldateien verfügen, so dass Einträge (protokollierte Ereignisse ab der Schwere „Warning) über einen Zeitraum von bis zu einem Jahr darin vorgehalten werden können.

    <=

    Da sich die Menge an Einträgen nach der Größe der Einsatzumgebung richtet, ist die Speichergröße nach den in [gemSpec_Perf#3.1.1] beschriebenen Einsatzumgebungen (LE-Ux, x=1,2,3,4) ausreichend zu wählen.

    TIP1-A_4712

    Wenn LOG_SUCCESSFUL_CRYPTO_OPS = Enabled MUSS der Konnektor die folgenden erfolgreich durchlaufenen Außenoperationen protokollieren:
     - SignDocument,
     - VerifyDocument,
     - ExternalAuthenticate,
     - EncryptDocument,
     - DecryptDocument.
    Dazu MUSS er

    TUC_KON_256 {
         topic = „LOG/CRYPTO_OP“;
         eventType = Sec;
         severity = Info;
         parameters = („Operation=$Operationsname,
                               <für alle betroffenen Schlüssel:>
                                     Karte=$ICCSN,
                                     Keyref=<Referenz auf den Schlüssel>,
                                     CARD_HANDLE=$CardHandle,
                                     CardHolderName=$CardHolderName“);
                                     doDisp = false}

    aufrufen.

    <=

    TIP1-A_4713

    Wenn LOG_LEVEL_SYSLOG = Info MUSS der Konnektor herstellerspezifische Informationen über den laufenden Betrieb in das Systemprotokoll eintragen, um im Bedarfsfall das Verhalten des Konnektors analysieren zu können (Unterstützung der Fehlersuche etc.).

    Die Häufigkeit und der Inhalt der protokollierten Informationen sind herstellerspezifisch.

    <=

    TIP1-A_4714

    Der Konnektor MUSS Protokolleinträge so anlegen, dass eine Analyse der Einträge unterstützt wird:

    <=

    4.1.10.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.1.10.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.1.10.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.10.4.1 TUC_KON_271 „Schreibe Protokolleintrag“

    TIP1-A_4715

    Der Konnektor MUSS den technischen Use Case TUC_KON_271 „Schreibe Protokolleintrag” umsetzen.

    Tabelle 288: TAB_KON_607 – TUC_KON_271 „Schreibe Protokolleintrag“

    Element
    Beschreibung
    Name
    TUC_KON_271 „Schreibe Protokolleintrag“
    Beschreibung
    Dieser TUC schreibt einen Eintrag in ein Protokoll.
    Auslöser
    Aufruf durch Basisdienst, Fachmodul oder TUC_KON_256 „Systemereignis absetzen“
    Vorbedingungen
    Im Fall eines zu protokollierenden Ereignisses des Systeminformationsdienstes wird
    • eventType = "Op" gesetzt, wenn Event.Type gleich "Operation", "Infrastructure ", "Business " oder "Other" bzw.
    • eventType = "Sec", wenn Event.Type gleich "Security".
      Die Schwere entspricht der Event.Severity gemäß Schema EventService.xsd.
      Im Fall eines zu protokollierenden Fehlers wird
    • eventType = "Op" gesetzt, wenn ErrorType gleich "Technical", "Business", "Infrastructure" oder "Other" bzw.
      eventType = "Sec", wenn ErrorType gleich "Security".
      Die Schwere entspricht der Severity des Fehlers.

    Eingangs
    anforderung
    Keine
    Eingangsdaten
    • Zu protokollierendes Ereignis
      • fmName – optional/verpflichtend für Aufruf durch Fachmodule; default = „„
        (Name des aufrufenden Fachmoduls; das Ereignis wird in das entsprechende Konnektor-Protokoll geschrieben)
      • eventType [EventType]
        definiert den Protokolltyp, in welchen das Ereignis geschrieben wird;
        Sec = Security: Ereignis wird in das Securityprotokoll
                   geschrieben
        Op = Operation: Wenn fmName =„„ wird das Ereignis in das
                 Systemprotokoll geschrieben.
                 Wenn fmName gesetzt ist, wird das Ereignis in das durch
                 fmName definierte Fachmodul-Protokoll geschrieben.
        Perf = Performance: Wenn fmName =„„ wird das Ereignis in das
                   Konnektor-Performanceprotokoll geschrieben.
                   Wenn fmName gesetzt ist, wird das Ereignis in das
                   durch fmName definierte Fachmodul-Performance
                   protokoll geschrieben.
      • severity { [EventSeverity] , Debug}
        (Schwere mit: Debug = Debug Information, Info = Information, Warn = Warning, Err = Error, Fatal
      • parameters
        beinhaltet die Daten des Ereignisses, die im Protokolleintrag geschrieben werden
    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Nachbedingungen

    Standardablauf
     1.      Wenn eventType = Sec, so wird das Ereignis in das
       Sicherheitsprotokoll geschrieben. Falls fmName angegeben ist, wird
         er dem Eintrag hinzugefügt.
     2.      fmName ist angegeben (durch ein Fachmodul aufgerufen) und
        eventType = „Op“, so wird das Ereignis in das zugehörige
        Fachmodulprotokoll geschrieben.
     a.            Gemäß den Festlegungen in den jeweiligen
        Fachmodulspezifikationen (FM_<fmName>_LOG_LEVEL), werden
        nur Ereignisse in das Fachmodulprotokoll geschrieben, deren
        severity mindestens dem jeweils dort festgelegten Wert entsprechen.
     3.     fmName ist nicht angegeben (Aufruf durch ein Fachmodul) und
        eventType = „Op“, dann wird das Ereignis in das Systemprotokoll
        geschrieben.
     a.            Gemäß den Festlegungen in LOG_LEVEL_SYSLOG
        werden nur Ereignisse in das Systemprotokoll geschrieben, deren
        Schwere mindestens dem Wert von LOG_LEVEL_SYSLOG
        entsprechen.

     4.    Wurde der TUC durch ein Fachmodul aufgerufen (fmName ist
        angegeben) und ist eventType = Perf, so wird das Ereignis in das
        zugehörige Fachmodul-Performanceprotokoll geschrieben.

     5.    Wurde der TUC nicht durch ein Fachmodul aufgerufen (fmName
        ist nicht angegeben) und ist eventType = Perf, so wird das Ereignis
        in das Konnektor-Performanceprotokoll geschrieben.
         Die geschriebenen Protokolleinträge MÜSSEN mindestens folgende
        Attribute beinhalten:
    •     Datum und Uhrzeit
    •     Übergebenes Ereignis
          Die Speicherung erfolgt rollierend.
    Übersteigt die Anzahl der Einträge im Sicherheitsprotokoll SECURITY_LOG_SIZE, so werden ältere Einträge überschrieben. Für die anderen Protokolle beginnt das Überschreiben, wenn der jeweilige Speicherplatz für das Protokoll erschöpft ist. Dabei werden die nach der Reihenfolge der Erstellung ältesten Einträge überschrieben, unabhängig vom Zeitstempel des Logeintrags.
    Ist der Zeitstempel eines überschriebenen Logeintrags jünger als LOG_DAYS bzw. FM_<fmName>_LOG_DAYS bzw. SECURITY_LOG_DAYS, so wird der Fehlerzustand EC_LOG_OVERFLOW ausgelöst.

    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zu:
    a)  Aufruf von
         TUC_KON_256 {
            topic = „LOG/ERROR“;
             eventType = $ErrorType;
             severity = $Severity;
             parameters = („Error=$Fehlercode, Bedeutung=$Fehlertext“);
             doLog = false }
    b)  Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes

    (1)    In das Sicherheitsprotokoll kann nicht geschrieben werden: Fehlercode: 4152
    (2)    In das Fachmodulprotokoll kann nicht geschrieben werden: Fehlercode: 4151
    (3)    In das Systemprotokoll kann nicht geschrieben werden: Fehlercode: 4150
    (4)    In das Fachmodul-Performanceprotokoll kann nicht geschrieben werden: Fehlercode: 4217
    (5)    In das Konnektor-Performanceprotokoll kann nicht geschrieben werden: Fehlercode: 4216
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 289: TAB_KON_608 Fehlercodes TUC_KON_271 „Schreibe Protokolleintrag“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4150
    Technical
    Fatal
    Fehler beim Schreiben des Systemprotokolls
    4151
    Technical
    Fatal
    Fehler beim Schreiben eines Fachmodulprotokolls
    4152
    Security
    Error
    Fehler beim Schreiben des Sicherheitsprotokolls
    4216
    Technical
    Fatal
    Fehler beim Schreiben des Konnektor-Performanceprotokolls
    4217
    Technical
    Fatal
    Fehler beim Schreiben eines Fachmodul-Performanceprotokolls

    <=

    Die Darstellung PIC_KON_118 veranschaulicht den Aufbau der Protokolle für Plattform und Fachmodule und die Steuerung der Protokolleinträge in TUC_KON_271 „Schreibe Protokolleintrag“.

    Abbildung 20: PIC_KON_118 Aufbau und Struktur der Protokolldateien für Plattform und Fachmodule

    4.1.10.5 Operationen an der Außenschnittstelle

    Keine

    4.1.10.6 Betriebsaspekte

    TIP1-A_4716

    Der Administrator MUSS die durch den Protokollierungsdienst geschriebenen Protokolle über die Managementschnittstelle einsehen können.

    Eine Veränderung des Sicherheitsprotokolls DARF für den Administrator NICHT möglich sein.

    Das Löschen folgender Protokolle MUSS für den Administrator möglich sein:

    Der Konnektor MUSS den Export von Protokolleinträgen oder ganzen Protokolldateien unterstützen.

    Der Konnektor SOLL das Sortieren und Filtern der Protokolleinträge sowie das Suchen in den Protokolleinträgen unterstützen.

    <=

    TIP1-A_4996

    Nachdem sich der Administrator an der Managementschnittstelle angemeldet hat, MUSS der Konnektor ihn automatisch auf Sicherheitsprotokolleinträge hinweisen, die seit dem Ausloggen dieses Administrator aufgelaufen sind.

    <=

    TIP1-A_4717

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_609 vorzunehmen:

    Tabelle 290: TAB_KON_609 Konfigurationswerte des Protokollierungsdienstes (Administrator)

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    LOG_LEVEL_
    SYSLOG

    Info, Warning, Error, Fatal
    Der Administrator MUSS den Detaillierungsgrad des Systemprotokolls durch Festlegung der Mindest-Schwere zu protokollierender Einträge festlegen können.
    Default-Wert: Warning
    FM_<fmName>_
    LOG_LEVEL

    Debug, Info, Warning, Error, Fatal
    Der Administrator MUSS den Detaillierungsgrad des Fachmodulprotokolls durch Festlegung der Mindest-Schwere zu protokollierender Einträge festlegen können.
    Default-Wert: Warning
    SECURITY_LOG_SIZE X Einträge Der Administrator MUSS die Größe des Sicherheitsprotokolls angeben können (Anzahl der Einträge im Ringbuffer). 
    Mindestgröße: >= 10.000
    Maximalgröße: herstellerspezifisch
    Default-Wert: >= 50.000
    SECURITY_LOG_DAYS X Tage Der Administrator MUSS die erwartete Anzahl der im Sicherheitsprotokoll gespeicherten Tage im Bereich 10 bis 365 konfigurieren können.
    Default-Wert: 180
    LOG_DAYS
    X Tage
    Der Administrator MUSS die Anzahl der gespeicherten Tage für das Systemprotokoll und das Performanceprotokoll festlegen können. Der Konnektor kann Protokolleinträge, die älter als LOG_DAYS sind, zyklisch löschen.
    Dabei DARF der eingestellte Wert NICHT unter der Mindestgröße von 10 Tagen oder über der Maximalgröße von einem Jahr (365 Tage) liegen.

    Default-Wert: 180
    FM_<fmName>_
    LOG_DAYS

    X Tage
    Der Administrator MUSS die Anzahl der gespeicherten Tage für die fachmodulspezifischen Protokolle festlegen können. Es kann je Fachmodul einen Konfigurationsparameter für LOG_DAYS geben, der gemeinsam für das Fachmodulprotokoll und das Fachmodul-Performanceprotokoll gilt.
    Der Konnektor kann Protokolleinträge, die älter als FM_<fmName>LOG_DAYS sind, zyklisch löschen.
    Dabei DARF der eingestellte Wert NICHT unter der Mindestgröße von 10 Tagen oder über der Maximalgröße von einem Jahr (365 Tage) liegen.
    Default-Wert: 180
    Die Definition des fachmodulspezifischen Konfigurationswertes ist Bestandteil der entsprechenden Fachmodulspezifikation.
    Ist kein fachmodulspezifischer Konfigurationsparameter spezifiziert, dann gilt LOG_DAYS.
    LOG_SUCCESSFUL_
    CRYPTO_OPS

    Enabled/Disabled
    Der Administrator MUSS festlegen können, ob auch erfolgreich ausgeführte Kryptooperationen im Sicherheitslog protokolliert werden sollen.
    Default-Wert: Disabled

    <=

    4.1.10.6.1 TUC_KON_272 „Initialisierung Protokollierungsdienst

    TIP1-A_4718

    Der Konnektor MUSS den technischen Use Case TUC_KON_272 „Initialisierung Protokollierungsdienst” umsetzen.

    Tabelle 291: TAB_KON_610 – TUC_KON_272 „Initialisierung Protokollierungsdienst“

    Element
    Beschreibung
    Name
    TUC_KON_272 „Initialisierung Protokollierungsdienst”
    Beschreibung
    Der Konnektor muss zum Bootup den Protokollierungsdienst starten und die Existenz und Schreibbarkeit der Protokolle sicherstellen.
    Eingangs
    anforderung

    Keine
    Auslöser und Vorbedingungen
    Bootup
    Eingangsdaten
    Keine
    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
    1.       Prüfen, ob Schreib-/Lesezugriff auf Sicherheitsprotokoll möglich ist
    2.       Prüfen, ob Schreib-/Lesezugriff auf Systemprotokoll möglich ist
    3.       Prüfen, ob Schreib-/Lesezugriff auf Fachmodulprotokolle möglich ist
    4.       Prüfen, ob Schreib-/Lesezugriff auf Konnektor-Performanceprotokoll möglich ist
    5.       Prüfen, ob Schreib-/Lesezugriff auf Fachmodul-Performanceprotokolle möglich ist
    Varianten/
    Alternativen

    Keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Standardablaufs führen zu:
    a)         Aufruf von TUC_KON_256 mit folgenden Parametern {
            topic = „LOG/ERROR“;
            eventType = $ErrorType;
            severity = $Severity;
            parameters = („Error=$Fehlercode, Bedeutung=$Fehlertext“);
            doLog = false }

    b)         Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
          (1)    Zugriff nicht möglich: Fehlercode: 4153
          (2)    Zugriff nicht möglich: Fehlercode: 4154
          (3)    Zugriff nicht möglich: Fehlercode: 4155
          (4)    Zugriff nicht möglich: Fehlercode: 4218
          (5)    Zugriff nicht möglich: Fehlercode: 4219
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 292: TAB_KON_611 Fehlercodes TUC_KON_272 „Initialisiere Protokollierungsdienst“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4153
    Technical
    Fatal
    Zugriff auf Sicherheitsprotokoll nicht möglich
    4154
    Technical
    Fatal
    Zugriff auf Systemprotokoll nicht möglich
    4155
    Technical
    Fatal
    Zugriff auf Fachmodulprotokolle nicht möglich
    4218
    Technical
    Fatal
    Zugriff auf Konnektor-Performanceprotokoll nicht möglich
    4219
    Technical
    Fatal
    Zugriff auf Fachmodul-Performanceprotokoll nicht möglich

    <=

    4.1.11 TLS-Dienst

    Fachmodule müssen gesicherte Verbindungen zu Fachdiensten in der TI aufbauen können. Dabei sollen sie sich mit einer Organisationsidentität (einer SM-B) authentisieren können. Der TLS-Dienst stellt hierfür TUCs für einen TLS-Verbindungsaufbau und -Verbindungsabbau zur Verfügung. Die gesicherte Kommunikation selbst erfolgt dann durch das Fachmodul unter Nutzung der etablierten Verbindung.

    Die Funktionalität steht nur zur Verfügung, wenn MGM_LU_ONLINE aktiv ist (siehe Kapitel 4.3.6)

    4.1.11.1 Funktionsmerkmalweite Aspekte
    4.1.11.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_4719

    Tritt das Ereignis „MGM/LU_CHANGED/LU_ONLINE“ ein, so MUSS

    <=

    4.1.11.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.1.11.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.11.4.1 TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“

    TIP1-A_4720-02

    Der Konnektor MUSS den technischen Use Case "Kartenbasierte TLS-Verbindung aufbauen" gemäß TUC_KON_110 umsetzen.

    Tabelle 293: TAB_KON_773 – TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“

    Element
    Beschreibung
    Name
    TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
    Beschreibung
    Der TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“ baut eine TLS-Verbindung zur angegebenen Zieladresse auf. Dabei kann für eine gegenseitige Authentisierung eine SM-B verwendet werden.
    Auslöser
    Aufruf durch ein Fachmodul
    Vorbedingungen
    Die für die Authentisierung adressierte Karte muss freigeschaltet sein
    Eingangsdaten
    • roleToMatch – optional/verpflichtend, wenn Rollenprüfung durchgeführt werden soll
    • cardSession – optional/verpflichtend, wenn Clientauthentisierung durchgeführt werden soll
      (CardSession einer SM-B)
    • targetUri
      (URI des Verbindungsziels)

    Komponenten
    Konnektor, eHealth-Kartenterminal, Karte, Server des Fachdienstes
    Ausgangsdaten
    • tlsConnectiontId
      (ConnectionIdentifier der TLS-Verbindung)

    Standardablauf
    Der Konnektor MUSS folgende Schritte durchlaufen:
    1.  Auflösen des FQDN im targetUri per 'TUC_KON_361 „DNS Namen
         auflösen“

    2.  TLS-Verbindung mit ermittelter Adresse aufbauen:
     a)       Prüfe Server-Zertifikat mittels TUC_KON_037 „Zertifikat prüfen“  {
           certificate = C.FD.TLS-S;
                  qualifiedCheck = not_required;
                  offlineAllowNoCheck = true;
                  policyList  = oid_fd_tls_s;
                  intendedKeyUsage= intendedKeyUsage(C.FD.TLS-S);
                  intendedExtendedKeyUsage = id-kp-serverAuth;
                  validationMode  = OCSP}

           Das Server-Zertifikat MUSS C.FD.TLS-S sein
      b)       Prüfe in a) zurückgegebene Rolle („ermittelte Rolle“) ==
          
    roleToMatch
      c)       Wenn cardSession übergeben: Clientauthentisierung mittels
          ID.HCI.AUT. Der Konnektor darf nur dann das ECC-Zertifikat von der SMC-B auswählen, wenn auch das Serverzertifikat ein ECC-Zertifikat ist.

    3.  tlsConnectiontId der erzeugten Verbindung zurückgeben

    Varianten/
    Alternativen

    • Keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu einem Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
    (1)    Der Name der Gegenstelle kann nicht aufgelöst werden
    (2b)  Rollenprüfung fehlgeschlagen: Fehlercode 4220
    (2)    Server konnte nicht authentisiert werden: Fehlercode 4156
    (2)    Clientauthentisierung fehlgeschlagen: Fehlercode 4157
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    Tabelle 294: TAB_KON_612 Fehlercodes TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4156
    Security
    Error
    Server konnte bei TLS-Verbindungsaufbau nicht authentisiert werden
    4157
    Security
    Error
    Clientauthentisierung bei TLS-Verbindungsaufbau fehlgeschlagen
    4220
    Security
    Error
    Rollenprüfung bei TLS-Verbindungsaufbau fehlgeschlagen

    <=

    4.1.11.4.2 TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“

    TIP1-A_4721

    Der Konnektor MUSS den technischen Use Case "Kartenbasierte TLS-Verbindung abbauen" gemäß TUC_KON_111 umsetzen.

    Tabelle 295: TAB_KON_774 - TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“

    Element
    Beschreibung
    Name
    TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
    Beschreibung
    Der TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“ dient der geregelten Beendigung einer TLS-Verbindung, die zuvor über TUC_KON_110 aufgebaut wurde.
    Auslöser
    Aufruf durch ein Fachmodul
    Vorbedingungen
    Mittels TUC_KON_110 wurde eine TLS-Verbindung aufgebaut
    Eingangsdaten
    • tlsConnectiontId
      (ConnectionIdentifier der TLS-Verbindung)

    Komponenten
    Konnektor, Server des Fachdienstes
    Ausgangsdaten
    Keine
    Standardablauf
    Der Konnektor MUSS folgende Schritte durchlaufen:
    1. Trennen der über tlsConnectiontId adressierten TLS-Verbindung
    Varianten/
    Alternativen

    keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu einem Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes:
    (1) Keine Verbindung mit angegebenem TLSConnectionIdentifier
             vorhanden: Fehlercode 4158

    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine


    Tabelle 296: TAB_KON_613 Fehlercodes TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4158
    Technical
    Error
    Adressierte TLS-Verbindung nicht vorhanden

    <=

    4.1.11.5 Operationen an der Außenschnittstelle

    Keine.

    4.1.11.6 Betriebsaspekte

    TIP1-A_4722

    Wenn MGM_LU_ONLINE = Enabled, MUSS der Basisdienst TLS-Dienst nach dem Bootup zur Nutzung zur Verfügung stehen.

    Wenn MGM_LU_ONLINE = Disabled, DARF der Basisdienst TLS-Dienst nach dem Bootup NICHT zur Nutzung zur Verfügung stehen.

    <=

    4.1.12 LDAP-Proxy

    Der Konnektor ermöglicht es Clientsystemen und Fachmodulen durch Nutzung des LDAP-Proxies Daten aus dem Verzeichnisdienst der TI-Plattform (VZD) abzufragen. Die Kommunikation erfolgt über das LDAPv3 Protokoll.

    Die Funktionalität steht nur zur Verfügung, wenn MGM_LU_ONLINE=Enabled ist (siehe Kapitel 4.3.6)

    4.1.12.1 Funktionsmerkmalweite Aspekte

    Keine.

    4.1.12.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_5516

    Tritt das Ereignis „MGM/LU_CHANGED/LU_ONLINE“ ein, so MUSS

    <=

    4.1.12.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.1.12.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.1.12.4.1 TUC_KON_290 „LDAP-Verbindung aufbauen“

    TIP1-A_5517-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_290 „LDAP-Verbindung aufbauen“ gemäß TAB_KON_805 umsetzen.

    Tabelle 297: TAB_KON_805 - TUC_KON_290 „LDAP-Verbindung aufbauen“

    Element
    Beschreibung
    Name
    TUC_KON_290 „LDAP-Verbindung aufbauen“
    Beschreibung
    Initiiert durch einen Verbindungsaufbau des LDAP-Clients zum Konnektor baut der Konnektor eine TLS-gesicherte Verbindung zum VZD auf.
    Auslöser
    LDAP (oder LDAPS wenn ANCL_TLS_MANDATORY=Enabled) Verbindungsaufbau von einem Fachmodul oder einem Clientsystem ist abgeschlossen. Bei Verwendung von LDAPS authentisiert sich der Konnektor beim LDAP-Client mit der Identität ID.AK.AUT.
    Vorbedingungen
    • MGM_LU_ONLINE=Enabled
    Eingangsdaten
    keine
    Komponenten
    Konnektor, VZD
    Ausgangsdaten
    keine
    Standardablauf
    1.  Der Konnektor ermittelt den FQDN und Port des VZD durch eine DNS-SD Namensauflösung gemäß [RFC6763] mit dem Bezeichner ”_ldap._tcp.vzd.<DNS_TOP_LEVEL_DOMAIN_TI>.”
    2.  Der Konnektor baut eine LDAPS-Verbindung zum VZD auf. Dabei wird das Serverzertifikat des Verzeichnisdienst C.ZD.TLS-S nach TUC_PKI_018 geprüft (PolicyList: oid_zd_tls_s (gemäß gemSpec_OID), intendedKeyUsage: intendedKeyUsage(C.ZD.TLS-S), ExtendedKeyUsages: serverAuth (1.3.6.1.5.5.7.3.1), Offlinemodus: nein, TOLERATE_OCSP_FAILURE: false , Prüfmodus: OCSP)
    Varianten/Alternativen
    keine
    Fehlerfälle

    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    <=

    4.1.12.4.2 TUC_KON_291 „Verzeichnis abfragen“

    TIP1-A_5518

    Der Konnektor MUSS den technischen Use Case TUC_KON_291 „Verzeichnis abfragen“ gemäß TAB_KON_815 umsetzen.

    Tabelle 298: TAB_KON_815 – TUC_KON_291 „Verzeichnis abfragen“

    Element
    Beschreibung
    Name
    TUC_KON_291 „Verzeichnis abfragen“
    Beschreibung
    Der Konnektor leitet als LDAP-Proxy einen Search Request des LDAP-Clients an den VZD weiter. Vom VZD empfängt der Konnektor eine Search Response und leitet diese an den LDAP-Client weiter.
    Auslöser
    Aufruf durch einen LDAPv3 Search Request von einen Fachmodul-TUC oder einem Clientsystem
    Vorbedingungen
    • MGM_LU_ONLINE=Enabled
    • Eine LDAPv3-Verbindung LDAP-Client sowie eine LDAPv3 Verbindung vom Konnektor zum VZD wurden aufgebaut (TUC_KON_290 „LDAP-Verbindung aufbauen“)
    Eingangsdaten
    • LDAPv3 Search Request gemäß [RFC4511]#4.5.1
    Komponenten
    Konnektor, VZD
    Ausgangsdaten
    • LDAPv3 Search Response gemäß [RFC4511]#4.5.2
    Standardablauf
    1.       Der Konnektor führt TUC_VZD_0001 „search_Directory” mit dem vom LDAP-Client empfangenen Search Request als Eingangsdaten aus und empfängt die LDAPv3 Search Response vom VZD (entspricht den Ausgangsdaten).
    Varianten/Alternativen
    keine
    Fehlerfälle
    Auftretende Fehler werden gemäß [RFC4511]# Appendix A behandelt.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine
    <=

    4.1.12.4.3 TUC_KON_292 „LDAP-Verbindung trennen"

    TIP1-A_5519

    Der Konnektor MUSS den technischen Use Case „LDAP-Verbindung trennen" gemäß TAB_KON_816 umsetzen.

    Tabelle 299: TAB_KON_816 – TUC_KON_292 „LDAP-Verbindung trennen"

    Element
    Beschreibung
    Name
    TUC_KON_292 „LDAP-Verbindung trennen"
    Beschreibung
    Der Konnektor beendet die Verbindung zum VZD und zum LDAP-Client.
    Auslöser
    Aufruf durch einen LDAPv3 Unbind Request von einen Fachmodul-TUC oder einem Clientsystem
    Vorbedingungen
    • MGM_LU_ONLINE=Enabled
    • Eine LDAPv3-Verbindung LDAP-Client sowie eine LDAPv3 Verbindung vom Konnektor zum VZD wurden aufgebaut (TUC_KON_290 „Verbindungsaufbau zum VZD“)
    Eingangsdaten
    keine
    Komponenten
    Konnektor, VZD
    Ausgangsdaten
    keine
    Standardablauf
    1.      Der Konnektor empfängt vom LDAP-Client einen Unbind Request gemäß [RFC4511]#4.3.
    2.      Der Konnektor sendet zum VZD einen Unbind Request.
    3.      Der Konnektor beendet die Verbindung zum VZD und zum LDAP Client gemäß [RFC4511]#5.3.
    Varianten/Alternativen
    keine
    Fehlerfälle
    Auftretende Fehler werden gemäß [RFC4511]# Appendix A behandelt.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    <=

    4.1.12.4.4 TUC_KON_293 „Verzeichnisabfrage abbrechen"

    TIP1-A_5520

    Der Konnektor MUSS den technischen Use Case TUC_KON_293 „Verzeichnisabfrage abbrechen" gemäß TAB_KON_817 umsetzen.

    Tabelle 300: TAB_KON_817 – TUC_KON_293 „Verzeichnisabfrage abbrechen“

    Element
    Beschreibung
    Name
    TUC_KON_293 „Verzeichnisabfrage abbrechen"
    Beschreibung
    Der Konnektor bricht einen unbeantworteten Search Request ab.
    Auslöser
    Aufruf durch einen LDAPv3 Abandon Request von einen Fachmodul-TUC oder einem Clientsystem
    Vorbedingungen
    • MGM_LU_ONLINE=Enabled
    • Ein Search Request wurde vom Konnektor empfangen und an den VZD weitergeleitet (TUC_KON_291 „Verzeichnis Abfragen“). Der Request wurde vom VZD noch nicht beantwortet.
    Eingangsdaten
    keine
    Komponenten
    Konnektor, VZD
    Ausgangsdaten
    keine
    Standardablauf
    1.      Der Konnektor empfängt vom LDAP-Client einen Abandon Request gemäß [RFC4511]#4.11.
    2.      Der Konnektor sendet zum VZD einen Abandon Request gemäß [RFC4511]#4.11
    Varianten/Alternativen
    keine
    Fehlerfälle
    Auftretende Fehler werden gemäß [RFC4511]# Appendix A behandelt.
    Nichtfunktionale Anforderungen
    keine
    Zugehörige Diagramme
    keine

    <=

    4.1.12.5 Operationen an der Außenschnittstelle
    4.1.12.5.1 Unterstützte LDAPv3 Operationen

    TIP1-A_5521

    Der Konnektor MUSS an der Client-Schnittstelle die folgenden LDAPv3 Operationen gemäß [RFC4511] anbieten.

    Andere LDAPv3 Operationen werden mit dem LDAP-Fehler unwillingToPerform (53) beantwort.
    Wenn ANCL_TLS_MANDATORY=Enabled, muss der Konnektor sicherstellen, dass nur über eine LDAPS-Verbindung (Voreinstellung TCP Port 636) Daten abgefragt werden können.
    Wenn ANCL_TLS_MANDATORY=Disabled, muss der Konnektor sicherstellen, dass über eine LDAP-Verbindung (Voreinstellung TCP Port 389) und über eine LDAPS-Verbindung (Voreinstellung TCP Port 636) Daten abgefragt werden können.
    Fehler müssen gemäß [RFC4511]#Appendix A behandelt werden.
    <=

    4.1.12.6 Betriebsaspekte

    keine

    4.1.13 Authentifizierungsdienst

    Der Authentifizierungsdienst bietet Clientsystemen und Fachmodulen eine Schnittstelle zum Signieren von Binärstrings zum Zweck der externen Authentisierung.

    Innerhalb des Authentifizierungsdienstes werden folgende Präfixe für Bezeichner verwendet:

    Eine Prüfung der Signatur bietet der Konnektor nicht an.

    4.1.13.1 Funktionsmerkmalweite Aspekte
    4.1.13.1.1 Externe Authentisierung

    TIP1-A_5437-02

    Der Signaturdienst MUSS für die Operation ExternalAuthenticate die Signaturverfahren entsprechend TAB_KON_780 – Signaturverfahren Externe Authentisierung unterstützen.

    Tabelle 301: TAB_KON_780 – Signaturverfahren Externe Authentisierung

    Signaturformat
    Standard
    Dokument
    formate
    QES/
    nonQES
    Bemerkung
    PKCS#1
    (V2.1)

    [RFC3447]
    Binär
    nonQES
    Die Low-Level-Signatur von Bitstrings DARF NUR in Verbindung mit dem zur Authentisierung vorgesehenen Schlüssel des HBAx und des SM-B genutzt werden.
    Die Nutzung ist auf Bitstrings (Hash-Werte) von maximal 512 bit Länge beschränkt.
    ECDSA [BSI-TR-03111] Binär nonQES
        
    <=

    TIP1-A_5149-01

    Der Hersteller des Konnektors MUSS den Anwender (Clientsystem) im Handbuch des Konnektors geeignet und ausreichend darüber informieren, dass die Operation ExternalAuthenticate nur zu Authentisierungszwecken mit dem Authentisierungsschlüssel des HBAx und des SM-B verwendet werden darf. <=

    4.1.13.2 Durch Ereignisse ausgelöste Reaktionen

    keine

    4.1.13.3 Interne TUCs

    keine

    4.1.13.4 Operationen an der Außenschnittstelle

    TIP1-A_5665-03

    Der Konnektor MUSS Clientsystemen den Basisdienst Authentifizierungsdienst anbieten.


    Tabelle 302: TAB_KON_839 Basisdienst Authentifizierungsdienst

    Name
    AuthSignatureService
    Version (KDV)
    7.4.0 (WSDL-Version)
    7.4.1 (WSDL-Version)

    Namensraum
    Siehe GitHub
    Namensraum-Kürzel
    SIG für Schema und SIGW für WSDL
    Operationen
    Name
    Kurzbeschreibung
    ExternalAuthenticate
    Binärstring signieren (nonQES)
    WSDL
    AuthSignatureService_V7_4_1.wsdl
    AuthSignatureService.wsdl (WSDL-Version 7.4.0)

    Schema
    Kein

    <=

    4.1.13.4.1 ExternalAuthenticate

    TIP1-A_5439

    Der Authentifizierungsdienst des Konnektors MUSS an der Clientschnittstelle eine Operation ExternalAuthenticate anbieten.

    Tabelle 303: TAB_KON_781 Operation ExternalAuthenticate

    Name
    ExternalAuthenticate
    Beschrei
    bung
    Diese Operation versieht einen Binärstring der maximalen Länge 512 Bit mit einer nicht-qualifizierten elektronischen Signatur (nonQES).
    Dazu wird das Signaturverfahren PKCS#1 oder ECDSA verwendet. Das AUT-Zertifikat der SM-B und das AUT-Zertifikat des HBAx werden unterstützt.
    Aufruf
    parameter


    Name
    Beschreibung
    CONN:
    CardHandle
    Identifiziert die zu verwendende Signaturkarte.
    Die Operation unterstützt HBAx und SM-B.
    CCTX:
    Context
    Aufrufkontext für HBAx:
    MandantId, ClientSystemId, WorkplaceId, UserId verpflichtend
    Aufrufkontext für SM-B:
    MandantId, ClientSystemId, WorkplaceId verpflichtend; UserId nicht ausgewertet
    SIG:
    Optional
    Inputs
    Enthält optionale Eingangsparameter:


    SIG:
    Binary
    String
    Dieses Element enthält im Kindelement dss:Base64Data den zu signierenden Binärstring.
    Das XML Attribut SIG:BinaryString/dss:Base64Data/@MimeType MUSS den Wert "application/octet-stream" haben.
    Die maximale Länge des Binärstrings beträgt 512 Bit entsprechend der maximal zu erwartenden Hash-Größe.
    Aus der Länge des Binärstrings wird auf das verwendete Hashverfahren geschlossen. Es werden folgende Längen unterstützt:  
    • 256 Bit: SHA-256 (OID 2.16.840.1.101.3.4.2.1)
    • 384 Bit: SHA-384 (OID 2.16.840.1.101.3.4.2.2)
    • 512 Bit: SHA-512 (OID 2.16.840.1.101.3.4.2.3)
    Im Falle des Signaturverfahrens RSASSA-PKCS1-v1_5 werden SHA-256, SHA-384 und SHA-512 unterstützt.
    Im Falle des Signaturverfahrens RSASSA-PSS wird SHA-256 unterstützt.
    Im Falle des Signaturverfahrens ECDSA wird SHA-256 unterstützt.
    Für die Signaturerstellung gilt:
    • Im Falle des Signaturverfahrens RSASSA-PKCS1-v1_5 beginnt der Konnektor die Ausführung der Methode EMSA-PKCS1-v1_5-ENCODE nach [RFC3447], Abschnitt 9.2, mit Schritt 2, Erstellung des DigestInfo-Datenfeldes.
    • Im Falle des Signaturverfahrens RSASSA-PSS  beginnt der Konnektor die Ausführung der Methode EMSA-PSS-ENCODE nach [RFC3447], Abschnitt 9.1.1, mit Schritt 3.
    • Im Falle des Signaturverfahrens ECDSA erfolgt die Signaturerstellung gemäß [BSI-TR-03111]#4.2.1. Als Eingangsparameter wird der Hash vom Aufrufer in SIG: BinaryString übergeben.
    dss:
    Signature
    Type
    Durch dieses in [OASIS-DSS] (Abschnitt 3.5.1) beschriebene Element wird der Typ der zu erzeugenden Signatur bestimmt. Als Signaturtyp wird unterstützt :
    • PKCS#1-Signatur
      Durch Übergabe der URI urn:ietf:rfc:3447 wird eine PKCS#1 (Version 2.1) Signatur gemäß [RFC3447] erzeugt, die als dss:Base64Signature mit der oben genannten URI zurückgeliefert wird.
    • ECDSA-Signatur
      Durch Übergabe der URI urn:bsi:tr:03111:ecdsa wird eine ECDSA-Signatur gemäß [BSI-TR-03111]#4.2.1 erzeugt, die als dss:Base64Signature mit der oben genannten URI zurückgeliefert wird.
    Andere SignatureType-Angaben führen zu einer Fehlermeldung 4111 (Ungültiger Signaturtyp oder Signaturvariante).
    Fehlt dieses Element, so wird ebenfalls der Signaturtyp PKCS#1-Signatur verwendet.
    SIG:
    Signature
    Schemes
    Durch dieses Element wird für PKCS#1-Signaturen zwischen den folgenden SignatureScheme-Optionen unterschieden:
    • RSASSA-PSS
    • RSASSA-PKCS1-v1_5
    Fehlt dieses Element, so wird als Default-SignatureScheme RSASSA-PSS gewählt.
    Rückgabe


    CONN:
    Status
    Enthält den Status der ausgeführten Operation.
    dss:
    Signature
    Object
    Enthält im Erfolgsfall die erzeugte Signatur in Form eines dss:SignatureObject-Elements gemäß [OASIS-DSS] (Abschnitt 3.2).
    Der Signaturwert wird im XML-Element
    dss:SignatureObject/dss:Base64Signature
    übergeben. Die Signatur wird binär gemäß [BSI-TR-03111]#5.2.2 in der ASN.1 Struktur ECDSA-Sig-Value zurückgegeben.
    Das XML-Attribut dss:SignatureObject/dss:Base64Signature/@Type kennzeichnet durch den Wert:
    • urn:ietf:rfc:3447 den Signatur-Typ PKCS#1
    bzw.
    • urn:bsi:tr:03111:ecdsa den Signatur-Typ ECDSA.
    Die XML-Elemente
    dss:SignatureObject/ds:Signature
    dss:SignatureObject/dss:Timestamp
    dss:SignatureObject/dss:SignaturePtr
    dss:SignatureObject/dss:Other
    werden nicht verwendet.
    Vorbeding
    ungen
    Keine
    Nachbeding
    ungen
    Keine
    Der Ablauf der Operation ExternalAuthenticate ist in Tabelle TAB_KON_782 beschrieben:

    Tabelle 304: TAB_KON_782 Ablauf Operation ExternalAuthenticate

    Nr.
    Aufruf Technischer Use Case oder Interne Operation
    Beschreibung
    1.
    checkArguments
    Alle übergebenen Parameterwerte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
    2.
    TUC_KON_000 „Prüfe Zugriffs- berechtigung“
    Die Prüfung erfolgt durch den Aufruf
    TUC_KON_000 {$context.mandantId; $context.clientsystemId; $context.workplaceId; $context.userId; $cardHandle}
    Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus TUC_KON_000 ab.
    3.
    TUC_KON_026 „Liefere CardSession“
    Ermittle CardSession über TUC_KON_026 { MandantId, CsId, CardHandle, UserId }
    4.
    TUC_KON_218 „Signiere“
    Signaturberechnung durch Aufruf des TUC_KON_218 {
    PinRef = PIN.CH bzw. PIN.SMC;
    KeyRef = PrK.HP.AUT bzw. PrK.HCI.AUT;
    AlgorithmusID = signPKCS1_V1_5 oder signPSS oder signECDSA;
    DTBS = Binärstring
    }

    Tabelle 305: TAB_KON_783 Übersicht Fehler Operation ExternalAuthenticate

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen TUCs können folgende weitere Fehlercodes auftreten:
    4000
    Technical
    Error
    Syntaxfehler
    4058
    Security
    Error
    Aufruf nicht zulässig
    Die folgende Tabelle führt die zulässigen privaten Schlüssel für die Operation ExternalAuthenticate auf:

    Tabelle 306: TAB_KON_784 Privater Schlüssel je Karte für ExternalAuthenticate

    Karte
    Schlüssel
    SM-B
    PrK.HCI.AUT in DF.ESIGN
    HBAx
    PrK.HP.AUT in DF.ESIGN
    <=

    4.1.13.5 Betriebsaspekte

    Keine

    4.1.14 Betriebsdatenmeldedienst

    A_21136

    Der Konnektor MUSS die Operation I_Registration_Service#sendData benutzen, um die Betriebsdaten täglich zu versenden.
    <=

    A_21137

    Der Konnektor MUSS die Betriebsdaten als XML-Dokument gemäß dem Schema „conn/OperatingData.xsd“ mit

    senden. <=

    A_21225

    Der Konnektor MUSS die XML Elemente der Betriebsdaten gemäß der Annotations im Schema OperatingData.xsd befüllen. <=

    A_21138

    Liefert I_Registration_Service einen Fehler, MUSS der Konnektor das Senden der Betriebsdaten 3 Mal im Abstand von 5 Minuten erneut versuchen. <=

    A_21139

    Meldet I_Registration_Service, dass die Soap Operation sendData nicht vorhanden ist, DARF der Konnektor die Operation NICHT sofort wiederholen. Erst zum nächsten regulären Termin soll wieder gesendet werden. <=

    A_21140

    Der Konnektor DARF NICHT personenbezogene, personenbeziehbare oder medizinische Daten senden. <=

    A_23275

    Der Konnektor SOLL dem Administrator an der Management-Oberfläche ein manuelles Versenden der Betriebsdaten ermöglichen. Dabei wird die Operation I_Registration_Service#sendData aufgerufen. <=

    4.2 Netzkonnektor

    4.2.1 Anbindung LAN/WAN

    Unter Anbindung LAN/WAN werden die Mechanismen beschrieben, mit denen der Konnektor auf der einen Seite in das lokale Netz der Einsatzumgebung, auf der anderen Seite in die TI bzw. die Bestandsnetze angebunden wird. Diese wesentlichen Aspekte betreffen Routing und Firewall.

    Innerhalb des Kapitels Anbindung LAN/WAN werden folgende Präfixe für Bezeichner verwendet:

    4.2.1.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4723

    Der Konnektor MUSS sich nach den in [RFC1812#1.1.3] definierten Rahmenbedingungen als IP Version 4 (IPv4) Router verhalten.
    Hiervon ausgenommen sind die in den folgenden Kapiteln aufgeführten Anforderungen des [RFC1812]:

    Die in [RFC2644] geforderten Aktualisierungen zum [RFC1812] müssen vom Konnektor umgesetzt werden.
    <=

    TIP1-A_5406

    Der Konnektor DARF NICHT IP-Pakete mit gesetzter Source Route Option gemäß [RFC791] erzeugen oder weiterleiten.

    <=

    In der folgenden Anforderung wird die Terminologie gemäß [RFC2663] verwendet.

    TIP1-A_5407

    Der Konnektor MUSS für die Kommunikation aus den Adressbereichen NET_LEKTR-Umgebung mit den Adressbereichen NET_TI_OFFENE_FD und ANLW_BESTANDSNETZE eine Network Address Port Translation (NAPT) gemäß [RFC3022#2.2, 3, 4.1-4.3] vornehmen.
    Für die Umsetzung der Private Local Address aus den Adressbereichen der Einsatzumgebung MUSS die IP-Adresse VPN_TUNNEL_TI_INNER_IP als Global Address genutzt werden.
    Der Konnektor MUSS für die Kommunikation aus den Adressbereichen der NET_LEKTR-Umgebung mit dem Internet über den VPN-Tunnel SIS eine Network Address Port Translation (NAPT) gemäß RFC3022#2.2, 3, 4.1-4.3 vornehmen. Für die Umsetzung der Local Address MUSS die IP-Adresse VPN_TUNNEL_SIS_INNER_IP als Global Address genutzt werden.
    <=

    TIP1-A_4724

    Der Konnektor MUSS sicherstellen, dass nur über den LAN-Adapter (Adressen aus ANLW_LAN_NETWORK_SEGMENT oder Adressen aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES) mit den Clientsystemen und den Kartenterminals kommuniziert werden kann.
    <=

    TIP1-A_4725

    Für den Betrieb in Reihe (ANLW_ANBINDUNGS_MODUS=InReihe) MUSS der Konnektor den WAN-Adapter für den Zugang zum Internet über das IAG der Einsatzumgebung verwenden.

    <=

    TIP1-A_4726

    Der Hersteller des Konnektors MUSS sicherstellen, dass eine Anbindung an das Transportnetz/Internet nur möglich ist, wenn (MGM_LU_ONLINE=Enabled) gesetzt ist.
    <=

    TIP1-A_4728

    Der Konnektor MUSS IP Version 4 (IPv4) für alle seine IP-Schnittstellen unterstützen.
    Die Hardware des Konnektors MUSS für den Einsatz von IPv4 und IPv6 im Dual-Stack-Mode geeignet sein.
    Bis zu einer Migration von IPv4 auf IPv6 MUSS der Konnektor sämtliche empfangene IP-Pakete der Version 6 (IPv6) verwerfen.
    <=

    TIP1-A_4728-01

    Der Konnektor MUSS IP Version 4 (IPv4) und IP Version 6 (IPv6) für alle seine physikalischen Adapter unterstützen.
    Die Hardware des Konnektors MUSS für den Einsatz von IPv4 und IPv6 im Dual-Stack-Mode geeignet sein.
    <=

    TIP1-A_4729

    Dynamische Routing-Protokolle dürfen vom Konnektor nicht eingesetzt werden. Wird in einem der an den Konnektor angeschlossenen Netzwerke ein dynamisches Routing genutzt, so DÜRFEN Routing Updates vom Konnektor NICHT akzeptiert werden und keine Routen eingetragen werden.

    <=

    TIP1-A_5152

    Falls Parameter MGM_LU_ONLINE=Enabled, MUSS der Konnektor einmal täglich TUC_KON_283 „Infrastruktur Konfiguration aktualisieren aufrufen.

    <=

    4.2.1.1.1 Netzwerksegmentierung

    In Anlehnung an die in der [gemSpec_Net#2.3.3] definierten Netzwerksegmente werden in der Konnektorspezifikation die folgenden Bezeichner verwendet:

    Tabelle 307: TAB_KON_680 Mapping der Netzwerksegmente

    ReferenzID im
    Konnektor
    Adressbereich für die TI-Produktivumgebung
    Adressbereich für die TI-Testumgebung
    Adressbereich für die TI-Referenzumgebung
    NET_SIS
    TI_Dezentral_SIS
    - Konnektoren
    TI_Test_Dezentral_SIS
    - Konnektoren
    Ist durch den Testbetriebsverantwortlichen zu definieren.
    NET_TI_
    DEZENTRAL
    TI_Dezentral
    - Konnektoren
    TI_Test_Dezentral
    - Konnektoren
    Ist durch den Testbetriebsverantwortlichen zu definieren.
    NET_TI_
    ZENTRAL
    TI_Zentral
    - Zentrale Dienste
    TI_Test_Zentral
    - Zentrale Dienste
    Ist durch den Testbetriebsverantwortlichen zu definieren.
    NET_TI_
    OFFENE_FD
    Anwendungsdienste
    - Offene Fachdienste
    - WANDA Smart
    - WANDA Basic
    Test_Anwendungsdienste
    - Offene Fachdienste
    - WANDA Smart
    - WANDA Basic
    Ist durch den Testbetriebsverantwortlichen zu definieren.
    NET_TI_
    GESICHERTE_
    FD
    Anwendungsdienste
    - Gesicherte Fachdienste
    Test_Anwendungsdienste
    - Gesicherte Fachdienste
    Ist durch den Testbetriebsverantwortlichen zu definieren.
    NET_LEKTR
    Liste der Netzwerke die in der Einsatzumgebung über den Konnektor erreichbar sind. Ein Eintrag der Liste enthält die Netzwerkadresse und den Netzwerkprefix.
    ANLW_
    BESTANDS
    NETZE
    Liste der an die TI angeschlossenen Bestandsnetze (u. a. das Sichere Netz der KVen). Ein Eintrag der Liste enthält die Netzwerkadresse und den Netzwerkprefix.
    ANLW_
    AKTIVE_
    BESTANDS
    NETZE
    Liste der an die TI angeschlossenen und aktivierten Bestandsnetze

    Tabelle 308: TAB_KON_681 Definition der vom Konnektor verwendeten VPN-Tunnel

    ReferenzID  
    Bedeutung/Belegung
    VPN_TI
    Logischer Adapter des VPN-Tunnel zur TI mit dessen VPN_TUNNEL_TI_INNER_IP aus dem Adresssegment NET_TI_DEZENTRAL
    VPN_SIS
    Logischer Adapter des VPN-Tunnel zur SIS mit dessen VPN_TUNNEL_SIS_INNER_IP aus dem Addresssegment NET_SIS

    Tabelle 309: TAB_KON_682 Definition der Konnektor IP-Adressen

    ReferenzID  
    Bedeutung/Belegung
    ANLW_LAN_IP_ADDRESS
    Dies ist die IP-Adresse des LAN-Adapters.
    Aus dem Netz der Einsatzumgebung (ANLW_LAN_NETWORK_SEGMENT) die vom Konnektor verwendete IP-Adresse. Unter dieser Adresse werden die Dienste des Konnektor im lokalen Netzwerk bereitgestellt.
    Diese Adresse entspricht dem in Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration definierten Parameter ANLW_LAN_IP_ADDRESS.
    ANLW_WAN_IP_ADDRESS
    Dies ist die IP-Adresse des WAN-Adapters.
    4.2.1.1.2 Routing und Firewall

    Darstellung der Kommunikationsregeln des Konnektors

    Diese Abbildung dient der Veranschaulichung der im Konnektor verwendeten Kommunikationsregeln welche in den nachfolgenden Afo definiert werden.


    Abbildung 21: PIC_KON_115 Kommunikationsregeln Konnektor

    TIP1-A_4730

    Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_GESICHERTE_FD verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.
    Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_GESICHERTE_FD für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Systemen des Netzwerksegments NET_TI_GESICHERTE_FD für folgende Fälle blockieren:
    Der Konnektor MUSS sicherstellen, dass die aus einer unterstützten Kommunikation mit Systemen aus dem Netzwerksegment NET_TI_GESICHERTE_FD bestimmten IP-Pakete ausschließlich in den VPN-Tunnel der TI (VPN_TI) geleitet werden.
    <=

    TIP1-A_5530

    Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_OFFENE_FD verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.
    Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_OFFENE_FD für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Systemen des Netzwerksegments NET_TI_OFFENE_FD für folgende Fälle blockieren:
    Der Konnektor MUSS sicherstellen, dass die aus einer unterstützten Kommunikation mit Systemen aus dem Netzwerksegment NET_TI_OFFENE_FD bestimmten IP-Pakete ausschließlich in den VPN-Tunnel der TI (VPN_TI) geleitet werden.
    <=

    TIP1-A_4731

    Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_ZENTRAL verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.

    Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_ZENTRAL für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Systemen des Netzwerksegments NET_TI_ZENTRAL für folgende Fälle blockieren:

    Der Konnektor MUSS sicherstellen, dass die aus einer unterstützten Kommunikation mit Systemen aus dem Netzwerksegment NET_TI_ZENTRAL bestimmten IP-Pakete ausschließlich in den VPN-Tunnel der TI (VPN_TI) geleitet werden.

    <=

    TIP1-A_4732

    Der Konnektor MUSS sicherstellen, dass die Adressen aus dem Adressbereich NET_TI_DEZENTRAL nur für die Kommunikation mit der TI/den weiteren Anwendungen des Gesundheitswesens in Form der inner IP (VPN_TUNNEL_TI_INNER_IP) des VPN-Tunnel der TI (VPN_TI) verwendet wird.
    Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments NET_TI_DEZENTRAL für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Systemen des Netzwerksegments NET_TI_DEZENTRAL für folgende Fälle blockieren:
    <=

    TIP1-A_4733

    Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich ANLW_AKTIVE_BESTANDSNETZE verworfen werden, wenn sie nicht aus dem VPN-Tunnel der TI (VPN_TI) stammen.
    Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments ANLW_AKTIVE_BESTANDSNETZE für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Systemen des Netzwerksegments ANLW_AKTIVE_BESTANDSNETZE für folgende Fälle blockieren:

    Der Konnektor MUSS sicherstellen, dass die aus einer unterstützten Kommunikation mit Systemen aus dem Netzwerksegment ANLW_AKTIVE_BESTANDSNETZE bestimmten IP-Pakete ausschließlich in den VPN-Tunnel der TI (VPN_TI) geleitet werden.
    <=

    TIP1-A_4734

    Der Konnektor MUSS sicherstellen, dass eine Adresse aus dem Adressbereich NET_SIS nur für die Kommunikation mit dem Internet (via SIS) in Form der inner IP (VPN_TUNNEL_SIS_INNER_IP) des VPN-Tunnel der SIS (VPN_SIS) verwendet wird.

    Der Konnektor MUSS insbesondere die Kommunikation mit Systemen des Netzwerksegments NET_SIS für folgende Fälle unterstützen:

    Der Konnektor MUSS die Kommunikation an seinen Außenschnittstellen mit NET_SIS für folgende Fälle blockieren:

    <=

    TIP1-A_4735

    Der Konnektor MUSS sicherstellen, dass IP-Pakete mit einer Absenderadresse aus dem Adressbereich NET_TI_ZENTRAL, NET_TI_GESICHERTE_FD; NET_TI_OFFENE_FD, NET_TI_DEZENTRAL, ANLW_AKTIVE_BESTANDSNETZE, ANLW_LAN_ADDRESS_SEGMENT, aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES oder ANLW_WAN_NETWORK_SEGMENT verworfen werden, wenn sie aus dem VPN-Tunnel der SIS (VPN_SIS) stammen.

    Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments Internet (via SIS) für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Internet (via SIS) für folgende Fälle blockieren oder umleiten:

    Der Konnektor MUSS sicherstellen, dass die für die Kommunikation mit dem Internet (via SIS) bestimmten IP-Pakete ausschließlich in den VPN-Tunnel des SIS (VPN_SIS) geleitet werden.

    <=

    TIP1-A_4736-02

    Der Konnektor MUSS sicherstellen, dass eingehende IP-Pakete von der Kommunikation mit dem Internet mit der Empfängeradresse ungleich (ANLW_LAN_IP_ADDRESS oder aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES wenn ANLW_WAN_ADAPTER_MODUS=DISABLED) oder (ANLW_WAN_IP_ADDRESS wenn ANLW_WAN_ADAPTER_MODUS=ENABLED) verworfen werden.
    Der Konnektor MUSS sicherstellen, dass ausgehende IP-Pakete für die Kommunikation mit dem Internet mit der Absenderadresse ungleich (ANLW_LAN_IP_ADDRESS oder aus einem der Netzwerksegmente in ANLW_LEKTR_INTRANET_ROUTES wenn ANLW_WAN_ADAPTER_MODUS=DISABLED) oder (ANLW_WAN_IP_ADDRESS wenn ANLW_WAN_ADAPTER_MODUS=ENABLED) verworfen werden.
    Der Konnektor MUSS die Kommunikation mit Systemen des Netzwerksegments Internet (via IAG) für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit Internet (via IAG) für folgende Fälle blockieren oder umleiten:
    <=

    TIP1-A_4737

    Der Konnektor MUSS sicherstellen, dass ausgehende IP-Pakete für die Kommunikation mit „Aktive Komponenten mit einer Absenderadresse ungleich ANLW_LAN_IP_ADDRESS, einer Adresse aus einem Netzwerksegment in ANLW_LEKTR_INTRANET_ROUTES oder 0.0.0.0 verworfen werden.

    Der Konnektor MUSS die Kommunikation mit „Aktive Komponenten für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit „Aktive Komponenten für folgende Fälle blockieren:

    <=

    TIP1-A_4738

    Der Konnektor MUSS die Kommunikation mit dem IAG der Einsatzumgebung für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit dem IAG der Einsatzumgebung für folgende Fälle blockieren:

    <=

    TIP1-A_4740

    Die Firewall des Konnektor MUSS alle vom Administrator in ANLW_FW_SIS_ADMIN_RULES definierten Firewall-Regeln als zusätzliche Einschränkung übernehmen.

    <=

    TIP1-A_4741

    Der Konnektor MUSS die Kommunikation mit Systemen aus einem Intranet-VPN (einem der Netzwerksegmente ANLW_LEKTR_INTRANET_ROUTES) für folgende Fälle unterstützen:

    <=

    TIP1-A_4742

    Der Konnektor MUSS die Kommunikation mit den Fachmodulen für folgende Fälle unterstützen:

    Der Konnektor MUSS insbesondere die Kommunikation an seinen Außenschnittstellen mit den Fachmodulen für folgende Fälle blockieren:

    <=

    TIP1-A_4744

    Die Firewall des Konnektor MUSS alle abgelehnten IP-Pakete verwerfen (DROP) ohne ein ICMP-Destination-Unreachable (Type 3) zu schicken.

    <=

    TIP1-A_4746

    Der Konnektor MUSS geeignete technische Funktionen zur Abwehr von IP-Spoofing und DoS/DDoS-Angriffen implementieren.

    Der Konnektor MUSS Martian Packets (Absender– oder Empfängeradressen aus den von der IETF als Special-Purpose definierten Netzbereichen), mindestens jedoch aus folgenden Netzbereichen 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 192.0.0.0/24, 192.0.2.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4 verwerfen. Die in [RFC1918] und [RFC 6598] definierten Netzbereiche sind hiervon ausgenommen.

    <=

    TIP1-A_4745

    Die Firewall des Konnektor MUSS TCP-Port-7(Echo)-Pakete verwerfen.
    Die Firewall des Konnektor MUSS ICMP-Echo-Request (Typ 8) und ICMP-Echo-Response (Typ 0) ausschließlich für die folgenden Kommunikationen zulassen:

    Die Firewall des Konnektors MUSS für alle anderen Kommunikationen ein ICMP-Echo-Request (Typ 8) verwerfen.
    <=

    TIP1-A_4747

    Der Konnektor MUSS alle IP-Protokolle außer 1 (ICMP), 4 (IP in IP (encapsulation)), 17 (UDP), 6 (TCP), 50 (ESP) und 108 (IPComp) für alle ein- oder ausgehenden Pakete an allen seinen Adaptern verwerfen.

    <=

    TIP1-A_4748

    Der Konnektor DARF seine Routing-Regeln NICHT durch IP-Kommunikation beeinflussen lassen, weder mittels eines Routing-Protokolls (wie BGP oder RIP) noch mittels ICMP-Kommandos (wie Redirect (5), Router Advertisement (9/10) oder auch Mobile Host Redirect (32)) sondern MUSS diese ausschließlich durch TUC_KON_304 „Netzwerk-Routen einrichten setzen.

    Die Firewall des Konnektor MUSS alle aus einem der Tunnel (VPN_TI oder VPN_SIS) kommenden DHCP-Pakete verwerfen.

    Die Firewall des Konnektors MUSS an den Konnektor gerichtete IPsec-Pakete (IKE, ESP und IPsec NAT-T) verwerfen, sofern sie nicht einer vom Konnektor initiierten IPsec-Verbindung (VPN_TI und VPN_SIS) zugeordnet werden können.

    <=

    TIP1-A_4749

    Der Konnektor MUSS gewährleisten, dass unmittelbar nach einer Änderung der Parameter eines Adapters (LAN-Adapter, WAN-Adapter, virtueller Adapter VPN_TI oder virtueller Adapter VPN_SIS) die Firewall des Konnektor neu erstellt und geladen wird.

    Wenn der WAN-Adapter verwendet wird (ANLW_WAN_ADAPTER_MODUS=ENABLED) DARF die Firewall des Konnektor bei einer Änderung der ANLW_WAN_IP_ADDRESS NICHT die Verbindungen über den LAN-Adapter durch einen Restart der Firewall beeinflussen.

    Wenn der WAN-Adapter verwendet wird (ANLW_WAN_ADAPTER_MODUS=ENABLED), DARF die Firewall des Konnektor bei einer Änderung der ANLW_LAN_IP_ADDRESS NICHT die Verbindungen über die Adapter WAN, VPN_TI oder VPN_SIS durch einen Restart der Firewall beeinflussen.

    <=

    Umsetzungshinweis für den Hersteller: Es können zwei getrennten Firewall-Regelsets für den LAN- bzw. für den WAN-Adapter verwendet werden.

    TIP1-A_4750

    Der Konnektor MUSS bei Start und Stopp der Firewall einen Protokolleintrag mit der Schwere „Warning und dem Typ „Operations sowie mindestens folgenden Informationen generieren:

    Der Konnektor MUSS bei Konfigurationsänderungen der Firewall einen Protokolleintrag mit der Schwere „Warning und dem Typ „Operations sowie mindestens folgenden Informationen generieren:

    Der Konnektor MUSS für alle vom Konnektor ausgehenden, nicht zugelassenen Kommunikationsversuche einen Protokolleintrag mit der Schwere „Warning und dem Typ „Security sowie mindestens folgenden Informationen generieren:

    Der Konnektor MUSS für alle verworfenen IP-Spoofing- und Martian-Packets einen Protokolleintrag mit der Schwere „Warning und dem Typ „Security sowie mindestens folgenden Informationen generieren:

    Der Konnektor MUSS für alle von der Firewall verworfenen IP-Pakete einen Protokolleintrag mit der Schwere „Info und dem Typ „Security sowie mindestens folgenden Informationen generieren, wobei Layer 3 Broadcasts von der Protokollierung ausgenommen werden können:

    Der Konnektor MUSS für die Firewall-Protokollierung den TUC_KON_271 „Schreibe Protokolleintrag nutzen.

    <=

    4.2.1.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_4751

    Beim Auftreten eines der nachfolgenden Events MUSS der Konnektor den TUC_KON_305 „LAN-Adapter initialisieren“ starten.

    <=

    TIP1-A_4752

    Beim Auftreten eines der nachfolgenden Events MUSS der Konnektor TUC_KON_306 „WAN-Adapter initialisieren“ starten.

    <=

    TIP1-A_4753

    Beim Auftreten eines der nachfolgenden Events MUSS der Konnektor den TUC_KON_304 „Netzwerk-Routen einrichten aufrufen.

    <=

    4.2.1.3 Interne TUCs, nicht durch Fachmodule nutzbar
    4.2.1.3.1 TUC_KON_305 „LAN-Adapter initialisieren“

    TIP1-A_4754

    Der Konnektor MUSS den technischen Use Case TUC_KON_305 „LAN-Adapter initialisieren“ umsetzen.

    Tabelle 310: TAB_KON_614 - TUC_KON_305 „LAN-Adapter initialisieren“

    Element
    Beschreibung
    Name
    TUC_KON_305 LAN-Adapter initialisieren
    Beschreibung
    Initialisieren der LAN-Netzwerkschnittstelle
    Auslöser
    •       Event ANLW/LAN/IP_CHANGED
    •       Event DHCP/LAN_CLIENT/RENEW; BOOTUP
    Vorbedingungen
    •       Wenn die IP-Konfiguration des LAN-Adapters statisch (DHCP_CLIENT_LAN_STATE=Disabled) gesetzt wird, MUSS der Konnektor gewährleisten, dass alle Konfigurationsparameter gemäß „Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration„ vorab über die Managementschnittstelle gesetzt wurden.
    •       Wenn die IP-Konfiguration des LAN-Adapters dynamisch per DHCP (DHCP_CLIENT_LAN_STATE=Enabled) gesetzt wird, MUSS der DHCP-Client diese vorab gesetzt haben.
    Eingangsdaten
    Keine
    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
    1) Die in „Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration„ und „Tabelle TAB_KON_684 LAN-Adapter Erweiterte Parameter „ gesetzten Werte sind zur Konfiguration des LAN-Adapter zu verwenden.
    2) Rufe TUC_KON_304 „Netzwerk-Routen einrichten“
    3) Wenn (ANLW_WAN_ADAPTER_MODUS = DISABLED)
    und MGM_LU_ONLINE = ENABLED:
    • Rufe TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“.
    • Rufe TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“
    4) Firewall-Regeln aktualisieren und aktivieren. Tritt der Fehler 4164 auf, geht der Konnektor in den Betriebszustand EC_Firewall_Not_Reliable über.
    Varianten/
    Alternativen
    Keine

    Fehlerfälle

    ( 1) Fehlerhafte LAN IP-Konfiguration; 4162
    ( 4) Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen; 4164
    Nichtfunktionale
    Anforderungen
    Keine

    Zugehörige
    Diagramme
    Keine

    Tabelle 311: TAB_KON_615 Fehlercodes TUC_KON_305 „LAN-Adapter initialisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4162
    Technical
    Error
    Es liegt eine fehlerhafte LAN IP-Konfiguration vor.
    4164
    Technical
    Fatal
    Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen.
    <=

    4.2.1.3.2 TUC_KON_306 „WAN-Adapter initialisieren“

    TIP1-A_4755

    Der Konnektor MUSS den technischen Use Case TUC_KON_306 „WAN-Adapter initialisieren“ umsetzen.

    Tabelle 312: TAB_KON_616 - TUC_KON_306 „WAN-Adapter initialisieren“

    Element
    Beschreibung
    Name
    TUC_KON_306 WAN-Adapter initialisieren
    Beschreibung
    Initialisieren der WAN-Netzwerkschnittstelle
    Auslöser
    •      Event ANLW/WAN/IP_CHANGED
    •      Event DHCP/WAN_CLIENT/RENEW; BOOTUP
    Vorbedingungen
    Eingangsdaten
    Keine
    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
    1) Wenn ANLW_WAN_ADAPTER_MODUS = DISABLED oder MGM_LU_ONLINE = Disabled:
    a) Aktive VPN-Tunnel TI oder SIS (VPN_TI oder VPN_SIS) müssen gestoppt werden,
    2) Wenn ANLW_WAN_ADAPTER_MODUS = ENABLED und  MGM_LU_ONLINE = ENABLED:
    a) Der WAN-Adapter wird abhängig von DHCP_CLIENT_WAN_STATE statisch oder dynamisch über DHCP konfiguriert. Die in „Tabelle TAB_KON_685 WAN-Adapter IP-Konfiguration„ und „Tabelle TAB_KON_686 WAN-Adapter Erweiterte Parameter„ gesetzten Werte sind zur Konfiguration des WAN-Adapter zu verwenden.
    b) Rufe TUC_KON_304 „Netzwerk-Routen einrichten“
    c) Rufe TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“.
    d) Rufe TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“
    e) Firewall-Regeln aktualisieren und aktivieren. Tritt der Fehler 4164 auf, geht der Konnektor in den Betriebszustand EC_Firewall_Not_Reliable über.
    Varianten/
    Alternativen
    Keine
    Fehlerfälle
    ( 1) Fehlerhafte WAN IP-Konfiguration; 4163
    ( 2) Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen; 4164
    Nichtfunktionale
    Anforderungen
    Keine

    Tabelle 313: TAB_KON_617 Fehlercodes TUC_KON_306 „WAN-Adapter initialisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4163
    Technical
    Error
    Es liegt eine fehlerhafte WAN-IP-Konfiguration vor.
    4164
    Technical
    Fatal
    Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen.
    <=

    4.2.1.3.3 TUC_KON_304 „Netzwerk-Routen einrichten“

    TIP1-A_4758

    Der Konnektor MUSS den technischen Use Case TUC_KON_304 „Netzwerk-Routen einrichten“ umsetzen.

    Tabelle 314: TAB_KON_622 - TUC_KON_304 „Netzwerk-Routen einrichten“

    Element
    Beschreibung
    Name
    TUC_KON_304 Netzwerk-Routen einrichten
    Beschreibung
    Anpassen der Routing-Tabelle
    Auslöser
    • TUC_KON_305 „LAN-Adapter initialisieren“
    • TUC_KON_306 „WAN-Adapter initialisieren“
    • Event NETWORK/VPN_TI/UP
    • Event NETWORK/VPN_TI/DOWN
    • Event NETWORK/VPN_SIS/UP
    • Event NETWORK/VPN_SIS/DOWN
    • Event MGM/LU_CHANGED/LU_ONLINE
    Vorbedingungen
    keine
    Eingangsdaten
    •       IP-Konfiguration des LAN-Interface (gemäß Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration)
    •       IP-Konfiguration des WAN-Interface (gemäß Tabelle TAB_KON_685 WAN-Adapter IP-Konfiguration)
    •       ANLW_IAG_ADDRESS (IP-Adresse des IAG der Einsatzumgebung)
    •       DNS_SERVERS_INT
    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Nachbedingungen
    • Die Routing-Einträge im Konnektor wurden gesetzt.
    Standardablau
    Alle bestehenden Routen MÜSSEN vollständig durch die in diesem TUC ermittelten Routen ersetzt werden.

    1) Wenn (MGM_LU_ONLINE=Enabled)
    Der Konnektor MUSS die nachfolgenden Routen bereitstellen

    a)
           i.           Ziel: Lokale Netze der Einsatzumgebung
               gemäß ANLW_LEKTR_INTRANET_ROUTES

                Next Hop: gemäß
               ANLW_LEKTR_INTRANET_ROUTES

    b)             Wenn die VPN-Tunnel zur TI und zum SIS nicht
         aufgebaut sind:

           i.        Ziel: Default Route
               Next Hop: ANLW_IAG_ADDRESS
    c)             Wenn der VPN-Tunnel zur TI aufgebaut und der
        VPN-Tunnel zum SIS nicht aufgebaut sind:

           i.        Ziel: Default Route
               Next Hop: ANLW_IAG_ADDRESS

           ii.       Ziel: TI (NET_TI_OFFENE_FD,
               NET_TI_GESICHERTE_FD und NET_TI_ZENTRAL)
               Next Hop: Innere Tunnel IP-Adresse des VPN-
               Konzentrators TI

          iii.       Ziel: ANLW_AKTIVE_BESTANDSNETZE
               Next Hop: Innere Tunnel IP-Adresse des VPN-
               Konzentrators TI

          iv.       Ziel: VPN-Konzentrator TI
               Next Hop: ANLW_IAG_ADDRESS


    d)            Wenn die VPN-Tunnel zur TI und zum SIS
         aufgebaut sind:

            i.       Ziel: Default Route
               Next Hop: Innere Tunnel IP-Adresse des VPN-
               Konzentrators SIS

           ii.       Ziel: TI (NET_TI_OFFENE_FD,
               NET_TI_GESICHERTE_FD und NET_TI_ZENTRAL)
               Next Hop: Innere Tunnel IP-Adresse des VPN-
               Konzentrators TI

           iii.      Ziel: ANLW_AKTIVE_BESTANDSNETZE
               Next Hop: Innere Tunnel IP-Adresse des VPN-
               Konzentrators TI

           iv.      Ziel: VPN-Konzentrator TI
               Next Hop: ANLW_IAG_ADDRESS

           v.       Ziel: VPN-Konzentrator SIS
               Next Hop: ANLW_IAG_ADDRESS
    Hinweis: Wenn der VPN-Tunnel zur TI nicht existiert, kann
    auch kein VPN-Tunnel zum SIS existieren, da die Default
    Route zum IAG zeigen muss, um einen VPN-Tunnel zur TI
    aufbauen zu können.
    2) Wenn (MGM_LU_ONLINE=Disabled)
    1.          Der Konnektor MUSS die nachfolgenden Routen
         bereitstellen.

          i.        Ziel: Lokale Netze der Einsatzumgebung
                gemäß ANLW_LEKTR_INTRANET_ROUTES
               Next Hop: gemäß
               ANLW_LEKTR_INTRANET_ROUTES


    3) Firewall aktualisieren:
    Die Firewall des Konnektors MUSS die neu eingerichteten
    Routen berücksichtigen und seine Regeln entsprechend aktualisieren und aktivieren. Tritt der Fehler 4164 auf, geht der Konnektor in den Betriebszustand EC_Firewall_Not_Reliable über.

    Varianten/Alternativen
    Keine
    Fehlerfälle
    ( 1-2) Eine oder mehrere Variablen enthalten eine ungültige oder keine IP; 4167
    ( 3) Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen; 4164
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 315: TAB_KON_623 Fehlercodes TUC_KON_304 „Netzwerk-Routen einrichten“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4167
    Technical
    Fatal
    CreateRoutes:
    Ein oder mehrere Adressen sind ungültig.
    4164
    Technical
    Fatal
    Beim Aktualisieren oder Aktivieren der Firewall-Regeln ist es zu einem Fehler gekommen.

    <=

    4.2.1.4 Interne TUCs, auch durch Fachmodule nutzbar

    Keine.

    4.2.1.5 Operationen an der Außenschnittstelle

    Keine

    4.2.1.6 Betriebsaspekte

    TIP1-A_5414

    Der Konnektor MUSS in der Bootup-Phase zur Initialisierung des Funktionsmerkmals „Anbindung LAN/WAN:

    <=

    TIP1-A_4759

    Der Konnektor MUSS gewährleisten, dass die Konfiguration nur dann gespeichert wird, wenn alle Parameter der nachfolgenden Tabellen den dazugehörigen Bedingungen entsprechen, sowie grundsätzlich zulässige Werte darstellen (gemäß RFCs).
    Wenn die Konfiguration per Managementschnittstelle geändert wurde, MUSS das folgende Systemereignis ausgelöst werden:
    TUC_KON_256 {
          topic = "ANLW/LAN/IP_CHANGED";
          eventType = Op;
          severity = Info;
          parameters = („IP=$dieNeueIP”);
          doDisp = false}
    Wenn (DHCP_CLIENT_LAN_STATE=Disabled) gesetzt ist, MUSS der Administrator des Konnektor die Werte der folgenden Tabelle über die Managementschnittstelle setzen können.
    Wenn (DHCP_CLIENT_LAN_STATE=Enabled) gesetzt ist, MUSS der Administrator des Konnektor die Werte der folgenden Tabelle angezeigt bekommen, kann diese jedoch nicht ändern.


    Tabelle 316: TAB_KON_683 LAN-Adapter IP-Konfiguration

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    ANLW_LAN_IP_
    ADDRESS

    IP-Adresse
    Dies ist die IP-Adresse des LAN-Adapters.
    Nur wenn DHCP_CLIENT_LAN_STATE=Disabled MUSS der Administrator die LAN-seitige IP-Adresse des Konnektors setzen können.
    Diese IP-Adresse MUSS innerhalb des ANLW_LAN_NETWORK_SEGMENT liegen.
    ANLW_LAN_
    SUBNETMASK


    Subnetzmaske
    Dies ist die zu ANLW_LAN_IP_ADDRESS gehörende Subnetzmaske.
    Der Administrator MUSS die Subnetzmaske setzen können.
    Der Konnektor MUSS gewährleisten das nur eine gültige Subnetzmaske gespeichert werden kann.
    ANLW_LAN_
    NETWORK_
    SEGMENT

    IP-Adresse / Subnetzmaske

    ANLW_LAN_NETWORK_SEGMENT ist ein Zustandswert, der sich aus den Werten von ANLW_LAN_IP_ADDRESS und ANLW_LAN_SUBNETMASK ergibt.
    Der Wert bezeichnet ein lokales Netzwerk in der Umgebung des Anwenders an das der LAN-Adapter des Konnektors angeschlossen ist.
    Der Konnektor MUSS gewährleisten, das das Netzwerksegment NICHT mit einem der folgenden Netzwerksegmente überlappt:
    1. NET_TI_DEZENTRAL
    2. NET_TI_ZENTRAL
    3. NET_TI_OFFENE_FD
    4. NET_TI_GESICHERTE_FD
    5. NET_SIS
    6. ANLW_BESTANDSNETZE
    7. ANLW_AKTIVE_BESTANDSNETZE
    8. ANLW_WAN_NETWORK_SEGMENT
    9. ANLW_LEKTR_INTRANET_ROUTES
    Der Administrator des Konnektor MUSS die Werte der folgenden Tabelle über die Managementschnittstelle setzen können.

    Tabelle 317: TAB_KON_684 LAN-Adapter Erweiterte Parameter

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    ANLW_LAN_MTU
    Nummer
    Der Administrator MUSS Maximum Transmission Unit (MTU) setzen können.
    Der Konnektor MUSS sicherstellen, das der konfigurierte Wert in den Grenzen von 576 bis 9000 liegt.
    Default-Wert: 1400
    ANLW_LAN_PARAMETER
    Liste von IP, UDP und/oder TCP Parametern
    Der Administrator SOLL weitere Konfigurationsparameter gemäß [gemSpec_Net#2.2.2.1,2.5] konfigurieren können.

    <=

    TIP1-A_4760

    Der Konnektor MUSS gewährleisten, dass die Konfiguration nur dann gespeichert wird, wenn alle Parameter der nachfolgenden Tabellen den dazugehörigen Bedingungen entsprechen.
    Wenn die Konfiguration per Managementschnittstelle geändert wurde, MUSS das folgende Systemereignis ausgelöst werden:    
    TUC_KON_256 {
    topic = "ANLW/WAN/IP_CHANGED";
    eventType = Op;
    severity = Info;
    parameters = („IP=$dieNeueIP“);
    doDisp = false}

    Wenn (DHCP_CLIENT_WAN_STATE=Disabled) gesetzt ist, MUSS der Administrator des Konnektors die Werte der folgenden Tabelle über die Managementschnittstelle setzen können.
    Wenn (DHCP_CLIENT_WAN_STATE=Enabled) gesetzt ist, MUSS der Administrator des Konnektors die Werte der folgenden Tabelle angezeigt bekommen, kann diese jedoch nicht ändern.

    Tabelle 318: TAB_KON_685 WAN-Adapter IP-Konfiguration

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    ANLW_WAN_
    IP_ADDRESS

    IP-Adresse
    Dies ist die IP-Adresse des WAN-Adapters.
    Nur wenn DHCP_CLIENT_WAN_STATE=Disabled und ANLW_WAN_ADAPTER_MODUS=ENABLED MUSS der Administrator die WAN-seitige IP-Adresse des Konnektors setzen können.
    Diese IP-Adresse MUSS innerhalb des ANLW_WAN_NETWORK_SEGMENT liegen.
    ANLW_WAN_
    SUBNETMASK


    Subnetzmaske
    Dies ist die zu ANLW_WAN_IP_ADDRESS gehörende Subnetzmaske.
    Der Administrator MUSS die Subnetzmaske setzen können.
    Der Konnektor MUSS gewährleisten, dass nur eine gültige Subnetzmaske gespeichert werden kann.
    ANLW_WAN_
    NETWORK_
    SEGMENT

    IP-Adresse / Subnetzmaske

    ANLW_WAN_NETWORK_SEGMENT ist ein Zustandswert, der sich aus den Werten von ANLW_WAN_IP_ADDRESS und ANLW_WAN_SUBNETMASK ergibt.
    Der Wert bezeichnet ein lokales Netzwerk in der Umgebung des Anwenders an das der WAN-Adapter des Konnektors angeschlossen ist.
    Der Konnektor MUSS gewährleisten, dass das Netzwerksegment nicht mit einem der folgenden Netzwerksegmente überlappt:
    1. NET_TI_DEZENTRAL
    2. NET_TI_ZENTRAL
    3. NET_TI_OFFENE_FD
    4. NET_TI_GESICHERTE_FD
    5. NET_SIS
    6. ANLW_ BESTANDSNETZE
    7. ANLW_AKTIVE_BESTANDSNETZE
    8. ANLW_LAN_NETWORK_SEGMENT
    9. ANLW_LEKTR_INTRANET_ROUTES
    Der Administrator des Konnektor MUSS die Werte der folgenden Tabelle über die Managementschnittstelle setzen können.

    Tabelle 319: TAB_KON_686 WAN-Adapter Erweiterte Parameter

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    ANLW_WAN_MTU
    Nummer
    Der Administrator MUSS Maximum Transmission Unit (MTU) setzen können.
    Der Konnektor MUSS sicherstellen, das der konfigurierte Wert in den Grenzen von 576 bis 9000 liegt.
    Default-Wert: 1400 
    ANLW_WAN_PARAMETER
    Liste von IP, UDP und/oder TCP Parametern
    Der Administrator SOLL weitere Konfigurationsparameter gemäß [gemSpec_Net#2.2.2.1,2.5] konfigurieren können.

    <=

    TIP1-A_4761

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_624 – „Konfigurationsparameter der Anbindung LAN/WAN vorzunehmen.
    Wenn (ANLW_INTRANET_ROUTES_MODUS = REDIRECT) gesetzt ist, MUSS der Konnektor jedes Paket aus einem konfigurierten Intranet mit einem ICMP-Redirect mit dem hinterlegten Next Hop beantworten und der Konnektor MUSS gewährleisten, dass keine IP-Pakete in eines oder mehrere der konfigurierten Intranet geroutet werden.
    Wenn (ANLW_INTRANET_ROUTES_MODUS = BLOCK) gesetzt ist, MUSS der Konnektor alle IP-Pakete für ein Intranet (gemäß ANLW_LEKTR_INTRANET_ROUTES) ablehnen.

    Tabelle 320: TAB_KON_624 – „Konfigurationsparameter der Anbindung LAN/WAN“

    ReferenzID

    Belegung

    Bedeutung und Administrator-Interaktion

    ANLW_
    ANBINDUNGS_
    MODUS

    InReihe

    Der Konnektor ist in Reihe zu dem IAG der Einsatzumgebung geschaltet.
    Wenn ANLW_WAN_ADAPTER_MODUS= ENABLED befindet sich der Konnektor in diesem Anbindungsmodus.
    Der Administrator MUSS diesen Wert einsehen und DARF ihn NICHT ändern können.
    Parallel

    Der Konnektor ist parallel (zu allen bestehenden Systemen) ins Netzwerk der Einsatzumgebung angebunden.
    Wenn ANLW_WAN_ADAPTER_MODUS= DISABLED befindet sich der Konnektor in diesem Anbindungsmodus.
    Der Administrator MUSS diesen Wert einsehen und DARF ihn NICHT ändern können.
    ANLW_
    INTERNET_
    MODUS

    SIS

    Der (am Konnektor LAN-seitig ankommende) Internet-Traffic wird per VPN an den SIS geschickt.
    IAG

    Bei Anfragen ins Internet wird der Aufrufer per ICMP-Redirect (Type 5) auf die Route zum IAG verwiesen.
    Wenn (ANLW_ANBINDUNGS_MODUS = InReihe) DARF dieser Wert NICHT auswählbar sein - statt dessen MUSS dann der Wert SIS verwendet werden.
    KEINER
    Es wird kein Traffic ins Internet geroutet
    ANLW_
    INTRANET_
    ROUTES_
    MODUS

    REDIRECT

    Der Konnektor MUSS sicherstellen, dass dieser Wert nur gesetzt werden kann, wenn der Administrator zuvor ein oder mehrere Intranet (ANLW_LEKTR_INTRANET_ROUTES) definiert hat.
    BLOCK

    Der Konnektor MUSS alle IP-Pakete für ein Intranet (gemäß ANLW_LEKTR_INTRANET_ROUTES) ablehnen.
    ANLW_WAN_
    ADAPTER_
    MODUS

    ENABLED

    Dieser Parameter ändert den Interface-Status des WAN-Adapters.
    Der Administrator MUSS diesen Wert einsehen können.
    Der Administrator MUSS diesen Wert ändern können.
    DISABLED

    Dieser Parameter ändert den Interface-Status des WAN-Adapters.
    Der Administrator MUSS diesen Wert einsehen können.
    Der Administrator MUSS diesen Wert ändern können.
    ANLW_
    LEKTR_
    INTRANET_
    ROUTES

    Tupel aus Netzwerksegment und dazugehörigem Next-Hop

    Der Administrator MUSS in diese Liste Einträge hinzufügen, editieren und löschen können.
    Liste von Routen zur Erreichung der Clientsysteme und Kartenterminals vom Konnektor; jeweils mit IP-Netzwerk dazugehörigem Next Hop.
    Die Netzwerksegmente DÜRFEN NICHT mit den Netzbereichen
    • NET_SIS
    • NET_TI_DEZENTRAL
    NET_TI_ZENTRAL
    • NET_TI_OFFENE_FD
    • NET_TI_GESICHERTE_FD
    • ANLW_BESTANDSNETZE
    kollidieren.
    ANLW_IAG_
    ADDRESS

    IP Adresse

    ANLW_IAG_ADDRESS ist die Adresse des Default Gateways. Diese IP-Adresse MUSS innerhalb des ANLW_WAN_NETWORK_SEGMENT liegen.
    Die Adresse wird entweder über DHCP automatisch (DHCP_CLIENT_WAN_STATE=ENABLED oder DHCP_CLIENT_LAN_STATE=ENABLED) oder anderenfalls manuell durch den Administrator konfiguriert. Bei automatischer Konfiguration per DHCP MUSS der Administrator den Wert von ANLW_IAG_ADDRESS ausschließlich einsehen können.
    ANLW_
    AKTIVE_
    BESTANDS
    NETZE

    Liste von IP-Address-Segmenten

    Der Administrator MUSS manuell aus der empfangenen Liste der zur Verfügung stehenden angeschlossene Netze des Gesundheitswesens mit WANDA Basic (gemäß TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“) einzelne deaktivieren, bzw. nach vorheriger Deaktivierung, freischalten können. Nur die freigegeben Netze werden in dieser Variablen erfasst und sind aus den Netzwerken der Einsatzumgebung  erreichbar.
    Wird eine Änderung an der Liste der freigegebenen Netze vorgenommen, so MUSS der Konnektor für jedes dieser freigegebenen Netz in DNS_SERVERS_BESTANDSNETZE ein DNS-Referer-Eintrag für jede der dazugehörigen Domains mit allen zugehörigen DNS-Servern im Konnektor hinterlegen. Die Werte hierzu werden der via TUC_KON_283 aktualisierten Bestandsnetze.xml entnommen.
    Für hier „nicht freigegebene“ oder zwischenzeitlich gelöschte Netze DARF der Konnektor NICHT Referer-Einträge in DNS_SERVERS_BESTANDSNETZE enthalten.
    Die Einträge in DHCP_AKTIVE_BESTANDSNETZE_ROUTES sind entsprechend zu aktualisieren.
    Der Konnektor MUSS nach jeder Änderung dieser Variablen durch den Administrator den TUC_KON_304 „Netzwerk-Routen einrichten“ aufrufen.
    ANLW_
    IA_
    BESTANDSNETZE



    AN

    Der Konnektor MUSS alle über TUC_KON_283 übermittelten angeschlossenen Netze des Gesundheitswesens mit WANDA Basic aktivieren. Eine spätere manuelle Deaktivierung über das Management-Interface durch den Administrator ist möglich. Dieses Verhalten ist als Standardverhalten zu konfigurieren.
    AUS

    Der Konnektor MUSS alle über TUC_KON_283 übermittelten angeschlossenen Netze des Gesundheitswesens mit WANDA Basic anbieten, diese aber nicht aktivieren. Eine spätere manuelle Aktivierung erfolgt über das Mangement-Interface durch den Administrator.


    <=

    TIP1-A_5537

    Der Konnektor MUSS über die Managmentschnittstelle die konfigurierten IP-Routen und die aktuelle IP-Routingtabelle mit mindestens folgenden Informationen anzeigen:

    <=

    TIP1-A_4762

    Im Anschluss an eine Anpassung der ANLW_FW_SIS_ADMIN_RULES MUSS der Konnektor die Firewall neu erstellen und laden.

    Tabelle 321: TAB_KON_625 - Konfigurationsparameter Firewall-Schnittstelle

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    ANLW_FW_SIS_
    ADMIN_RULES

    Firewall Regelset
    Der Administrator MUSS Firewall-Regeln (für den einschränkenden Zugriff auf die SIS), auf Grundlage der Parameter Absender-IP-Adresse, Empfänger-IP-Adresse, Protokoll (ggf. mit Absender-Port und Empfänger-Port) und Verbindungsrichtung, einfügen, editieren und löschen können.

    <=

    4.2.2 DHCP-Server

    Innerhalb des Kapitels DHCP-Servers werden folgende Präfixe für Bezeichner verwendet:

    4.2.2.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4763

    Der Konnektor MUSS an seiner LAN-Schnittstelle einen DHCP-Server gemäß [RFC2131] und [RFC2132] anbieten.

    <=

    4.2.2.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.2.2.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.2.2.4 Interne TUCs, auch durch Fachmodule nutzbar

    Keine.

    4.2.2.5 Operationen an der Außenschnittstelle
    4.2.2.5.1 Liefere Netzwerkinformationen über DHCP

    TIP1-A_4765

    Der DHCP-Server des Konnektors MUSS an der Client-Schnittstelle eine Operation zur Lieferung von Netzwerkinformationen über DHCP anbieten.

    Tabelle 322: TAB_KON_626 „Liefere Netzwerkinformationen über DHCP“

    Name
    Liefere Netzwerkinformationen über DHCP
    Beschreibung
    Der Konnektor MUSS anfragenden Clients per DHCP die konfigurierten Netwerkinformationen liefern (siehe Tabelle TAB_KON_628 und Tabelle TAB_KON_629).
    Aufrufparameter gemäß [RFC2131], [RFC2132]
    Rückgabe gemäß [RFC2131], [RFC2132]
    Standardablauf
    Die an den aufrufenden Client zu übergebenden Parameter ergeben sich aus Tabelle TAB_KON_628 und Tabelle TAB_KON_629:

    Falls DHCP_SERVER_STATE = Enabled:
    • Anhand der MAC-Adresse des anfragenden Client wird die Clientgruppe aus DHCP_SERVER_CLIENTGROUPS bzw. DHCP_SERVER_DEFAULT_CLIENTGROUP ausgewählt.
    • DHCP_OWNDNS_ENABLED
      •      Enabled: DNS-Server = <konnektoreigene Adresse>
      •      Disabled: DNS-Server = DHCP_DNS_ADDR
    • DHCP_NTP
      •      Enabled: NTP-Server = <konnektoreigene Adresse>
      •      Disabled: Keine Wertübermittlung
    • DHCP_OWNDGW_ENABLED
      •      Enabled: DGW = <konnektoreigene Adresse>
      •      Disabled: DGW = DHCP_DGW_ADDR
    • Falls Client-MAC-Adresse in DHCP_STATIC_LEASE
      •      IP_Address = die in der Static Lease konfigurierte Adresse.
    • Falls Client IP-Adresse = 0.0.0.0 oder innerhalb DHCP_SERVER_DYNAMIC_RANGE
      •      IP_Address = IP_Address aus DHCP_SERVER_DYNAMIC_RANGE
      •      Sonst: keine Zuweisung (Empfehlung: DHCPNAK an den Client)
    • Netzmaske = DHCP_IP_NETMASK
    • Domainname = DHCP_DOMAINNAME
    • Hostname = DHCP_HOSTNAME
    • Lease Dauer = DHCP_LEASE_TTL
    • Routen bestehend aus
      •      DHCP_AKTIVE_BESTANDSNETZE_ROUTES
      •      DHCP_INTRANET_ROUTES
      •      DHCP_ROUTES
    • Weitere DHCP-Optionen = DHCP_OPTIONS
    • MTU = ANLW_LAN_MTU
    Fehlercodes
    Vgl. [RFC2131], [RFC2132]
    Vorbedingungen
    Der DHCP-Server des Konnektors MUSS aktiviert und konfiguriert sein.
    Nachbedingungen
    Der DHCP-Server MUSS die DHCP-Antwort geliefert haben. Die Statusinformationen (z.B. Client Lease) müssen gemäß [RFC2131] gespeichert werden.
    Hinweise
    Keine

    <=

    4.2.2.6 Betriebsaspekte

    TIP1-A_4766

    Der DHCP- Server des Konnektors MUSS durch den Administrator über die Managementschnittstelle aktivierbar und deaktivierbar sein (gemäß TAB_KON_627). Der DHCP-Server MUSS bei der Auslieferung deaktiviert sein.

    Bei der Aktivierung MUSS der Konnektor den TUC_KON_343 "Initialisierung DHCP-Server" durchlaufen.

    Sobald DHCP_SERVER_STATE geändert wurde, muss TUC_KON_256{"DHCP/SERVER/STATECHANGED"; Op; Info; "STATE=$DHCP_SERVER_STATE "} aufgerufen werden.


    Tabelle 323: TAB_KON_627 „Aktivierung des DHCP-Servers“

    Referenz ID

    Belegung

    Bedeutung

    DHCP_SERVER_STATE

    Enabled / Disabled

    Der DHCP-Server MUSS durch den Administrator aktivierbar und deaktivierbar sein.


    <=

    TIP1-A_4767

    Der Konnektor MUSS die Möglichkeit bieten die in Tabelle TAB_KON_628 und Tabelle TAB_KON_629 beschriebenen Parameter des DHCP-Servers über die Managementschnittstelle zu konfigurieren.

    Tabelle 324: TAB_KON_628 „Basiskonfiguration des DHCP-Servers“

    Referenz ID
    Belegung
    Bedeutung
    DHCP_SERVER_NETWORK
    IP-Adresse
    IP-Netzwerk der Einsatzumgebung.
    DHCP_SERVER_BROADCAST
    IP-Adresse
    Die Broadcast-Adresse des Konnektors am LAN-Interface
    DHCP_SERVER_
    DYNAMIC_RANGE

    von – bis IP-Adresse
    Adressbereich für Adressen die dynamisch vergeben werden dürfen.
    DHCP_SERVER_
    CLIENTGROUPS

    Name der Clientgruppe;
    Liste an MAC-Adressen
    Der Konnektor MUSS dem Administrator über die Managementschnittstelle die Möglichkeit bieten mindestens zwei Client-Gruppen zu verwalten.
    DHCP_SERVER_
    DEFAULT_CLIENTGROUP

    Client-Gruppe
    Standardmäßig eingestellte Client-Gruppe. Wird verwendet falls DHCP-Anfrage keiner anderen Client-Gruppe zugeordnet werden kann.

    Tabelle 325: TAB_KON_629 „Client-Gruppenspezifische Konfigurationsoptionen des Konnektor-DHCP-Servers“

    ReferenzID
    Belegung
    Bedeutung
    Die gesamte Parameterliste ist für jede Client-Gruppe getrennt konfigurierbar
    DHCP_
    OWNDNS_
    ENABLED
    Enabled/Disabled
    Der Administrator MUSS konfigurieren können, ob der konnektoreigene DNS-Server als Parameter übergeben wird.
    Default-Wert: Disabled
    DHCP_DNS_
    ADDR
    IP-Adressen der DNS-Server
    Falls der konnektoreigene DNS-Server nicht übergeben werden soll, müssen die Adressen externer aus dem Netz der Einsatzumgebung erreichbaren DNS-Server als Parameter übergeben werden. Der Administrator MUSS diese Adressen konfigurieren können.
    DHCP_NTP
    Enabled/Disabled
    Der Administrator MUSS konfigurieren können, ob der Konnektor die Adresse des Konnektor internen NTP-Servers per DHCP an die Clients sendet.
    Default-Wert: Enabled
    DHCP_
    OWNDGW_
    ENABLED
    Enabled/Disabled
    Der Administrator MUSS konfigurieren können, ob der Konnektor beim Client als Default-Gateway gesetzt werden soll.
    Default-Wert: Disabled
    DHCP_DGW_
    ADDR
    IP-Adresse des DGW
    Falls der Konnektor nicht als Default Gateway gesetzt werden soll, muss die Adresse des zu verwendenden DGW als Parameter übergeben werden. Der Administrator MUSS die Adresse des DGW konfigurieren können.
    DHCP_IP_
    NETMASK
    Netzmaske
    Der Administrator MUSS die Netmask des Clients konfigurieren können.
    DHCP_
    DOMAINNAME
    Domainname
    Der Administrator MUSS den Domainnamen des Clients konfigurieren können.
    DHCP_
    HOSTNAME
    Liste von Tupel aus Hostname und Mac-Adresse
    Der Administrator MUSS eine Liste von Hostname der Clients konfigurieren können (Einträge einfügen, ändern, löschen).
    DHCP_
    STATIC_LEASE
    Liste von Tupel aus IP- und Mac-Adresse
    Der Administrator MUSS für jede MAC-Adresse Static Lease konfigurieren können.
    DHCP_
    LEASE_TTL
    X Minuten
    Der Administrator MUSS Lease-Dauer der dynamischen Adressen konfigurieren können.
    DHCP_
    AKTIVE_
    BESTANDS
    NETZE_
    ROUTES

    Liste von Tupel: Netzwerksegment je INTRANET und Adresse für Next Hop je freigegebenem angeschlossenen Netze des Gesundheitswesens mit WANDA Basic
    Der Administrator MUSS je freigegebenem angeschlossenen Netze des Gesundheitswesens mit WANDA Basic (aus ANLW_AKTIVE_BESTANDSNETZE) den an den Client zu übermittelnden Routen-Eintrag aktivieren oder deaktivieren können.
    DHCP_
    INTRANET_
    ROUTES
    Liste von Tupel: Netzwerksegment je INTRANET und Adresse für Next Hop in die definierten Intranets
    Der Administrator MUSS je Intranet-Tupel (aus ANLW_LEKTR_INTRANET_ROUTES) den an den Client zu übermittelnden Routen-Eintrag aktivieren oder deaktivieren können.
    DHCP_
    ROUTES
    Tupel Netzwerksegment und Adresse für Next Hop
    Der Administrator MUSS Routen zur Verteilung an die Clients frei konfigurieren können. Der Konnektor MUSS sicherstellen, diese Listeneinträge keine Überschneidungen mit folgenden Netzsegmenten haben:
    - dem Netzwerksegment ANLW_LAN_NETWORK_SEGMENT 
    - dem Netzwerksegment
    ANLW_WAN_NETWORK_SEGMENT
    - jedes Netzsegmente in
    ANLW_BESTANDSNETZE
    ANLW_AKTIVE_BESTANDSNETZE
    ANLW_LEKTR_INTRANET_ROUTES
    Die Routen SOLLEN über DHCP Option 121 (Windows Vista oder höher) bzw.
    DHCP Option 249 (Windows XP und darunter) verteilt werden.
    DHCP_
    OPTIONS
    Liste an weiteren DHCP-Optionen.
    Vom Administrator konfigurierbare Liste an weiteren DHCP-Options gemäß [RFC2132].
    Die Umsetzung dieser Konfigurationsmöglichkeit KANN entfallen.

    <=

    4.2.2.6.1 TUC_KON_343 „Initialisierung DHCP-Server“

    TIP1-A_4768

    Der Konnektor MUSS in der Bootup-Phase TUC_KON_343 "Initialisierung DHCP-Server" durchlaufen.

    Tabelle 326: TAB_KON_630 - TUC_KON_343 „Initialisierung DHCP-Server“

    Element
    Beschreibung
    Name
    TUC_KON_343 ”Initialisierung DHCP-Server”
    Beschreibung
    Falls DHCP-Server Konfiguration aktiv ist, muss der Konnektor in der Bootup-Phase oder bei einer Aktivierung des Servers den DHCP-Server starten.
    Anwendungsumfeld
    Bereitstellen der Netzwerkkonfiguration für den Betrieb
    Eingangsanforderung Keine
    Auslöser und Vorbedingungen
    Bootup oder Ereignis DHCP/SERVER/STATECHANGED
    Eingangsdaten
    Keine
    Komponenten
    Konnektor
    Ausgangsdaten Keine
    Standardablauf
    Falls DHCP_SERVER_STATE = enabled
      -               den DHCP-Server starten
    Falls DHCP_SERVER_STATE = disabled
      -               den DHCP-Server stoppen

    Varianten/Alternativen Keine
    Fehlerfälle
    4168: DHCP-Server konnte nicht gestartet werden
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 327: TAB_KON_631 Fehlercodes TUC_KON_343 „Initialisierung DHCP-Server“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4168
    Technical
    Error
    Der DHCP-Server des Konnektors konnte nicht gestartet werden.

    <=

    4.2.3 DHCP-Client

    Innerhalb des Kapitels DHCP-Client werden folgende Präfixe für Bezeichner verwendet:

    4.2.3.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4769

    Der Konnektor MUSS an seiner LAN- und WAN-Schnittstelle die Möglichkeit bieten jeweils DHCP zu nutzen.
    Der DHCP-Client des Konnektors MUSS die empfangenen Parameter wie folgt verwenden:

    Weitere DHCP-Parameter DÜRFEN nicht übernommen werden.
    <=

    4.2.3.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_4771

    Wenn das Ereignis DHCP/LAN_CLIENT/STATECHANGED oder DHCP/WAN_CLIENT/STATECHANGED empfangen wird, MUSS TUC_KON_341 DHCP-Informationen beziehen aufgerufen werden.

    <=

    4.2.3.3 Interne TUCs, nicht durch Fachmodule nutzbar
    4.2.3.3.1 TUC_KON_341 „DHCP-Informationen beziehen“

    TIP1-A_4772

    Der Konnektor MUSS den technischen Use Case TUC_KON_341 „DHCP-Informationen beziehen“ umsetzen.

    Tabelle 328: TAB_KON_632 – TUC_KON_341 „DHCP Informationen beziehen“

    Element
    Beschreibung
    Name
    TUC_KON_341 DHCP-Informationen beziehen
    Beschreibung
    Der Konnektor muss seine WAN- und/oder LAN-Schnittstelle individuell über einen DHCP-Server aus dem Netz der Einsatzumgebung beziehen können.
    Anwendungsumfeld
    Netzwerkkonfiguration für den Betrieb des Konnektors
    Eingangsanforderung
    Der Konnektor muss zur Netzwerk-Interface-Konfiguration DHCP nutzen sofern keine statischen Informationen vorhanden sind.
    Auslöser
    Bootup, Ablauf einer DHCP-Lease, manuell angestoßenes DHCP-Renew, Aktivierung der DHCP-Client-Funktionalität.
    Vorbedingung
    aktivierte DHCP-Client Funktion über die Variablen DHCP_CLIENT_LAN_STATE bzw. DHCP_CLIENT_WAN_STATE
    Eingangsdaten
    Netzwerk-Adapter (LAN oder WAN) für den DHCP-Informationen bezogen werden sollen
    Komponenten
    Konnektor
    Ausgangsdaten
    DHCP-Informationen vom DHCP-Server der Einsatzumgebung
    Standardablauf
    • Ermitteln von DHCP-Informationen (DHCPDISCOVER und DHCPREQUEST) gemäß [RFC2131], [RFC2132]
    • Übernahme der ermittelten Werte, ausschließlich für die in Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration bzw. Tabelle TAB_KON_685 WAN-Adapter IP-Konfiguration aufgeführten Variablen
    • Wenn DHCP Client LAN-Adapter, nur bei IP-Adressen-Wechsel: Erzeugen eines Events durch den Aufruf von TUC_KON_256{"DHCP/LAN_CLIENT/RENEW"; Op; Info; "IP_ADDRESS=$Belegung"}
    • Wenn DHCP Client WAN-Adapter, nur bei IP-Adressen-Wechsel: Erzeugen eines Events durch den Aufruf von TUC_KON_256{"DHCP/WAN_CLIENT/RENEW"; Op; Info; "IP_ADDRESS=$Belegung"}
    Varianten/Alternativen
    Keine
    Fehlerfälle
    4169: Konnektor erhält keine DHCP-Informationen
    4170: Konnektor besitzt identische IP-Adressen am WAN- und LAN-Interface
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine


    Tabelle 329: TAB_KON_633 Fehlercodes TUC_KON_341 „DHCP-Informationen beziehen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4169
    Technical
    Error
    Konnektor erhält keine DHCP-Informationen.
    4170
    Technical
    Error
    Konnektor besitzt identische IP-Adressen am WAN und LAN

    <=

    4.2.3.4 Interne TUCs, auch durch Fachmodule nutzbar

    Keine.

    4.2.3.5 Operationen an der Außenschnittstelle

    Keine.

    4.2.3.6 Betriebsaspekte

    TIP1-A_4773

    Die DHCP-Client Funktionalität MUSS für LAN- und WAN-Interface vom Administrator getrennt aktivierbar und deaktivierbar sein (gemäß TAB_KON_634). Falls der DHCP-Client nicht verwendet wird MUSS sichergestellt werden, dass eine statische Konfiguration, für den LAN-Adapter gemäß Tabelle TAB_KON_683 LAN-Adapter IP-Konfiguration bzw. für den WAN-Adapter gemäß Tabelle TAB_KON_685 WAN-Adapter IP-Konfiguration, existiert bevor die Netzwerkeinstellungen übernommen werden.
    Sobald Parameter geändert wurden, MUSS TUC_KON_256 „Systemereignis absetzen“ je nachdem auf welchem Interface der Client aktiviert oder deaktiviert wurde mit folgenden Parameter aufgerufen werden:

    TUC_KON_256{"DHCP/LAN_CLIENT/STATECHANGED"; Op; Info;    
    "STATE=$DHCP_CLIENT_LAN_STATE"; doDisp = false}
    oder
    TUC_KON_256{"DHCP/WAN_CLIENT/STATECHANGED "; Op; Info;    
    "STATE=$DHCP_CLIENT_WAN_STATE "; doDisp = false}


    Tabelle 330: TAB_KON_634 „Konfiguration des DHCP-Clients“

    ReferenzID
    Belegung
    Bedeutung
    DHCP_CLIENT_
    LAN_STATE

    Enabled/Disabled
    Der Administrator muss den DHCP-Client an der LAN-Schnittstelle aktivieren oder deaktivieren können.
    DHCP_CLIENT_
    WAN_STATE

    Enabled/Disabled
    Der Administrator muss den DHCP-Client an der WAN-Schnittstelle aktivieren oder deaktivieren können.

    <=

    TIP1-A_4774

    Der Administrator MUSS die Möglichkeit haben die DHCP-Lease des Konnektors für jedes Interface getrennt zu erneuern.
    <=

    TIP1-A_4776

    Falls der DHCP-Client auf der LAN-Seite nach einem Timeout von 30s keine IP-Adresse bezogen hat, MUSS gemäß [RFC3927] eine Default-Adresse aus 169.254/16 vergeben werden.
    <=

    4.2.4 VPN-Client

    Der VPN-Client beschreibt die Absicherung der Anbindung des Konnektors an die TI und die Bestandsnetze. Während der technische Kern dieser Funktion, der Aufbau der VPN- Kanäle zu den Konzentratoren, in [gemSpec_VPN_ZugD#TUC_VPN-ZD_0001] und [gemSpec_VPN_ZugD#TUC_VPN-ZD_0002] beschrieben wird, regelt dieses Kapitel die Interaktion, sowie die Konfiguration des VPN-Clients innerhalb des Konnektors.

    Innerhalb des Kapitels VPN-Client werden folgende Präfixe für Bezeichner verwendet:

    4.2.4.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4778

    Der Konnektor MUSS sich im Rahmen des IPsec-Verbindungsaufbaus gegenüber den VPN-Konzentratoren mit seiner Identität ID.NK.VPN ausweisen.

    Der VPN-Client im Konnektor MUSS das folgende Event generieren, sobald der VPN-Tunnel zur TI nicht mehr zur Verfügung steht:

    Rufe TUC_KON_256 {"NETWORK/VPN_TI/DOWN"; Op; Warning;}

    Der VPN-Client im Konnektor MUSS das folgende Event generieren, sobald der VPN-Tunnel zum SIS nicht mehr zur Verfügung steht:

    Rufe TUC_KON_256 {"NETWORKVPN_SIS/DOWN"; Op; Warning;}

    Der Hersteller des Konnektor MUSS sicherstellen, dass eine Anbindung an einen Konzentrator ausschließlich dann möglich ist, wenn (MGM_LU_ONLINE = Enabled) gesetzt ist.

    Der Administrator des Konnektor MUSS durch die Managementschnittstelle manuell einen Verbindungsaufbau und einen Verbindungsabbau eines VPN-Tunnel zur TI (VPN_TI) oder zu den SIS (VPN_SIS) initiieren können.

    <=

    TIP1-A_4779

    Der Konnektor MUSS gewährleisten, dass nach einem Fehler beim VPN-Verbindungsaufbau nicht unmittelbar ein weiterer Versuch des Verbindungsaufbaus durchgeführt wird.

    Hierzu MUSS der Hersteller ein inkrementelles (schrittweise anwachsend) Verfahren wählen, welcher den zeitlichen Abstand zwischen einzelnen Versuchen des VPN-Verbindungsaufbau definiert. Dieser Abstand MUSS maximal fünf Minuten betragen. (Diese Pause soll es dem Konnektor ermöglichen, noch ausreichend Ressourcen für die verbleibenden Services zur Verfügung zu stellen).

    <=

    4.2.4.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_4780

    Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen starten, sofern auch MGM_LU_ONLINE = Enabled.

    <=

    TIP1-A_4781

    Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen starten, sofern ANLW_INTERNET_MODUS = SIS, MGM_LU_ONLINE = Enabled und die Verbindung VPN-Konzentrator TI aufgebaut ist:

    <=

    TIP1-A_5417

    Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den VPN-Tunnel zur TI beenden:

    <=

    TIP1-A_4782

    Beim Auftreten einer der nachfolgenden Events MUSS der Konnektor den VPN-Tunnel zum SIS beenden:

    <=

    Hinweis: Wenn der IPsec-Tunnel VPN_SIS aufgebaut ist, zeigt die Default Route im Konnektor auf die innere Tunnel-IP-Adresse des VPN-Konzentrators SIS. Dies ist bei einer Trennung und dem Wiederaufbau der Verbindung VPN_TI zu beachten.

    4.2.4.3 Interne TUCs, nicht durch Fachmodule nutzbar
    4.2.4.3.1 TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“

    TIP1-A_4783

    Der Konnektor MUSS den technischen Use Case TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“ umsetzen.

    Tabelle 331: TAB_KON_635 – TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“

    Element
    Beschreibung
    Name
    TUC_KON_321 Verbindung zu dem VPN-Konzentrator der TI aufbauen
    Beschreibung
    Es wird ein IPsec-Tunnel zum VPN-Konzentrator der TI aufgebaut werden. Über den erfolgreichen Aufbau wird per Event informiert.
    Auslöser
    Bootup-Phase
    TUC_KON_305 „LAN-Adapter initialisieren“
    TUC_KON_306 „WAN-Adapter initialisieren“
    Event MGM/LU_CHANGED/LU_ONLINE
    Event NETWORK/VPN/CONFIG_CHANGED
    Optional: Änderungen ANLW_AKTIVE_BESTANDSNETZE
    Manueller Aufruf über Managementschnittstelle
    Vorbedingungen
    Der TUC_KON_304 „Netzwerk-Routen einrichten“ MUSS fehlerfrei durchgelaufen sein.
    Eingangsdaten

    Komponenten
    Konnektor
    Ausgangsdaten
    Der virtuelle Adapter VPN_TI mit der IP-Adresse VPN_TUNNEL_TI_INNER_IP des Konnektors wurde zur Verfügung gestellt.
    • Innere Tunnel IP-Adresse des VPN-Konzentrators TI
    • DNS_SERVERS_TI
    • VPN_KONZENTRATOR_TI_IP_ADDRESS
    • DOMAIN_SRVZONE_TI
    Standardablauf
    1) Wenn der Auslöser = Event NETWORK/VPN/CONFIG_CHANGED oder eine Änderung von ANLW_AKTIVE_BESTANDSNETZE ist, muss der VPN-Tunnel TI abgebaut werden.
    2) Wenn der VPN-Tunnel TI noch aktiv ist, ist der Ablauf abgeschlossen. Anderenfalls ist mit Ablaufschritt 3) fortzufahren.
    3) Prüfen, MGM_LU_ONLINE = Enabled, falls nicht ist der TUC ohne Ausgabe einer Fehlermeldung zu beenden.
    4) Prüfen, ob die im Konnektor hinterlegte CRL noch gültig ist.
    falls nicht, muss der TUC_KON_040 „CRL aktualisieren“ aufgerufen werden, Anschließend erneut prüfen, ob die im Konnektor hinterlegte CRL nun gültig ist.
    Falls die CRL nicht gültig ist, ist der TUC mit Fehler zu beenden.
    5) Aufrufen von TUC_VPN-ZD_0001 „IPsec Tunnel TI aufbauen”
    Die folgenden Rückgabewerte des TUC_VPN-ZD_0001 „IPsec Tunnel TI aufbauen” sind in die laufende Konfiguration des Konnektors zu übernehmen:
    • VPN_TUNNEL_TI_INNER_IP
    • DNS_SERVERS_TI
    6) Aufrufen von TUC_KON_304 „Netzwerk-Routen einrichten“
    Sobald der Tunnel erfolgreich aufgebaut wurde, ist der folgende Event zu generieren:
    TUC_KON_256 {"NETWORK/VPN_TI/UP"; Op; Info;IP= $VPN_TUNNEL_TI_INNER_IP}
    Varianten/Alternativen
    Keine
    Fehlerfälle
    (4) CRL ist abgelaufen (outdated);
    Herstellerspezifisch kann entweder (4a) oder (4b) umgesetzt werden:
    (4a) Kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde noch nicht festgestellt: 4173
    (4b) kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde bereits festgestellt: 4002
    (->4) Wenn Fehler 4173 bzw. 4002 nicht zutreffen, ist ein herstellerspezifischer Fehler zu verwenden.
    (5) VPN-Tunnel konnte nicht aufgebaut werden; Fehlercode: 4174
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 332: TAB_KON_636 Fehlercodes TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4002 Security Fatal Der Konnektor befindet sich in einem kritischen Betriebszustand
    4172
    Technical
    Fatal
    Es ist keine Online-Verbindung zulässig.
    4173
    Technical
    Fatal
    Die CRL ist nicht mehr gültig (outdated).
    4174
    Technical
    Fatal
    TI-VPN-Tunnel:
    Verbindung konnte nicht aufgebaut werden

    <=

    4.2.4.3.2 TUC_KON_322 „Verbindung zu dem VPN-Konzentrator des SIS aufbauen“

    TIP1-A_4784

    Der Konnektor MUSS den technischen Use Case TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“ umsetzen.

    Tabelle 333: TAB_KON_637 – TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“

    Element
    Beschreibung
    Name
    TUC_KON_322 Verbindung zu dem VPN-Konzentrator der SIS aufbauen
    Beschreibung
    Es muss ein IPsec-Tunnel zum VPN-Konzentrator der SIS aufgebaut werden
    Auslöser
    Bootup-Phase
    TUC_KON_305 „LAN-Adapter initialisieren
    TUC_KON_306 „WAN-Adapter initialisieren
    Event NETWORK/VPN/CONFIG_CHANGED
    Optional: Event MGM/LU_CHANGED/LU_ONLINE
    Manueller Aufruf über Managementschnittstelle
    Vorbedingungen
    ANLW_INTERNET_MODUS = SIS
    Die Verbindung VPN-Konzentrator TI ist aufgebaut.
    Der TUC_KON_304 „Netzwerk-Routen einrichten“ muss erfolgreich durchgeführt worden sein.
    Eingangsdaten
    Keine
    Komponenten
    Konnektor
    Ausgangsdaten
    Der virtuelle Adapter VPN_SIS mit der IP-Adresse VPN_TUNNEL_SIS_INNER_IP wurde zur Verfügung gestellt.
    •      Innere Tunnel-IP-Adresse des VPN-Konzentrators SIS
    •      VPN_KONZENTRATOR_SIS_IP_ADDRESS
    •      DNS_SERVER_SIS
    Standardablauf
    1) Wenn der Auslöser Event NETWORK/VPN/CONFIG_CHANGED ist, muss der VPN-Tunnel SIS abgebaut werden.
    2) Wenn der VPN-Tunnel SIS noch aktiv ist, ist der Ablauf abgeschlossen. Anderenfalls ist mit Ablaufschritt 3) fortzufahren.
    3) Prüfen, ob (MGM_LU_ONLINE=Enabled). falls nicht ist der TUC ohne Ausgabe einer Fehlermeldung zu beenden.
    4) entfällt
    5) Prüfen, ob die im Konnektor hinterlegte CRL noch gültig ist.
    falls nicht, MUSS der TUC_KON_040 „CRL aktualisieren“ aufgerufen werden, Anschließend erneut prüfen, ob die im Konnektor hinterlegte CRL nun gültig ist.
    Falls die CRL nicht gültig ist, ist der TUC mit Fehler zu beenden.
    6) Aufrufen von TUC_VPN-ZD_0002 „IPsec Tunnel SIS aufbauen”
    7) Aufrufen von TUC_KON_304 „Netzwerk-Routen einrichten“
    Sobald der Tunnel erfolgreich aufgebaut wurde, ist der folgende Event zu generieren:
    TUC_KON_256 {"NETWORK/VPN_SIS/UP"; Op; Info;IP= $VPN_TUNNEL_SIS_INNER_IP}
    Varianten/Alternativen
    Keine
    Fehlerfälle
    (3) Keine Online-Verbindung zulässig; 4172
    (5) CRL ist abgelaufen (outdated);
    Herstellerspezifisch kann entweder (5a) oder (5b) umgesetzt werden:
    (5a) Kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde noch nicht festgestellt: 4173
    (5b) kritischer Fehlerzustand EC_CRL_Out_Of_Date wurde bereits festgestellt: 4002
    (->5) Wenn Fehler 4173 bzw. 4002 nicht zutreffen, ist ein herstellerspezifischer Fehler zu verwenden.
    (6) VPN Tunnel konnte nicht aufgebaut werden; Fehlercode: 4176
    Nichtfunktionale
    Anforderungen
    Keine
    Zugehörige
    Diagramme
    Keine

    Tabelle 334: TAB_KON_638 Fehlercodes TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4002 Security Fatal Der Konnektor befindet sich in einem kritischen Betriebszustand
    4172
    Technical
    Fatal
    Es ist keine Online-Verbindung zulässig.
    4173
    Technical
    Fatal
    Die CRL ist nicht mehr gültig (outdated).
    4176
    Technical
    Fatal
    SIS-VPN-Tunnel:
    Verbindung konnte nicht aufgebaut werden

    <=

    4.2.4.4 Interne TUCs, auch durch Fachmodule nutzbar

    Keine

    4.2.4.5 Operationen an der Außenschnittstelle

    Keine

    4.2.4.6 Betriebsaspekte

    TIP1-A_5415

    Der Konnektor MUSS in der Bootup-Phase zur Initialisierung des Funktionsmerkmals „VPN-Client:

    <=

    TIP1-A_4785-03

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen am VPN-Client gemäß Tabelle TAB_KON_639 vorzunehmen.
    Der Konnektor MUSS bei einer Änderung der Konfigurationswerte den folgenden Event auslösen:
    Rufe TUC_KON_256 {"NETWORK/VPN/CONFIG_CHANGED"; Op; Info;; doDisp = false}

    Tabelle 335: TAB_KON_639 – Konfigurationsparameter VPN-Client

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    IKE_
    KEEPALIVE_
    MODUS

    Enabled/Disabled
    Der Administrator MUSS einstellen können, ob IKE Keep-Alive-Pakete gesendet werden.
    Ein Hinweis MUSS ausgegeben werden, dass dies bei Nutzung von Dial-Up-Verbindungen nicht zu empfehlen ist. Dies dient der Vermeidung von Kosten bei Nutzung eines Internetzugangs ohne Flatrate.
    Default-Wert: Enabled
    IKE_
    KEEPALIVE_
    INTERVAL

    X Sekunden
    Der Administrator MUSS die Zeit in Sekunden angeben können, nach der ein neues IKE Keep-Alive-Paket gesendet wird.
    Default-Wert: 30
    IKE_
    KEEPALIVE_
    RETRY

    X
    Der Administrator MUSS angeben können, nach wie vielen IKE Keep-Alive-Paketen ohne Acknowledge Message die Verbindung beendet wird.
    Default-Wert: 3
    VPN_IDLE_
    TIMEOUT_
    MODUS

    Enabled/Disabled
    Der Administrator MUSS einstellen können, ob nach Inaktivität die VPN-Verbindung automatisch abgebaut werden soll.
    Ein Hinweis MUSS ausgegeben werden, dass dies insbesondere bei Nutzung von Dial-Up-Verbindungen Enabled werden sollte.
    Default-Wert: Disabled
    VPN_IDLE_
    TIMEOUT

    X Sekunden
    Der Administrator MUSS die Zeit in Sekunden angeben können, nach der eine inaktive VPN-Verbindung zu einem Abbau der Verbindung führt.
    Default-Wert: 600
    NAT_
    KEEPALIVE_
    MODUS

    Enabled/Disabled
    Der Administrator MUSS einstellen können, ob NAT Keep-Alive-Pakete gesendet werden.
    Ein Hinweis MUSS ausgegeben werden, dass dies insbesondere bei Nutzung von Dial-Up-Verbindungen nicht zu empfehlen ist.
    Default-Wert: Enabled
    NAT_
    KEEPALIVE_
    INTERVAL

    X Sekunden
    Der Administrator MUSS die Zeit in Sekunden angeben können, nach der ein neues NAT Keep-Alive-Paket gesendet wird.
    Default-Wert: 20
    VPN_
    KONZENTRATOR_
    TI_IP_ADDRESS

    IP-Adresse
    IP-Adresse des VPN-Konzentrators TI im Transportnetz zu dem der IPsec-Tunnel VPN_TI aufgebaut wird. Der Wert kann vom Administrator nur eingesehen werden.
    VPN_
    KONZENTRATOR_
    SIS_IP_ADDRESS

    IP-Adresse
    IP-Adresse des VPN-Konzentrators SIS im Transportnetz zu dem der IPsec-Tunnel VPN_SIS aufgebaut wird. Der Wert kann vom Administrator nur eingesehen werden.
    VPN_TI_MTU
    Paketgröße in Byte
    Der Administrator MUSS die MTU für ESP-Pakete zur TI (excl. ESP-Header-Size) in den Grenzen von 576 bis 8076 konfigurieren können.
    Default-Wert: 1318
    VPN_SIS_MTU
    Paketgröße in Byte
    Der Administrator MUSS die MTU für ESP Pakete zum SIS (excl. ESP-Header-Size) in den Grenzen von 576 bis 8076 konfigurieren können.
    Default-Wert: 1318
    HASH_AND_URL
    Enabled/Disabled
    Der Administrator MUSS die Nutzung des hash&URL-Verfahrens zum Zertifikatsaustausch konfigurieren können.
    Wenn HASH_AND_URL = Enabled gesetzt ist, wird die URL für das hash&URL-Verfahren automatisch durch DNS SRV- und TXT-Anfragen mit Owner „_hashandurl._tcp.<DNS_DOMAIN_VPN_ZUGD_INT>„ ermittelt.
    Default-Wert: Disabled
    <=

    4.2.5 Zeitdienst

    Der Zeitdienst schafft die Grundlage einer gleichen Systemzeit für alle in der TI einzusetzenden Produkttypen. Grundsätzlich ist ein NTP-Server der Stratum-3-Ebene innerhalb des Konnektors erforderlich, welcher die Zeitangaben eines NTP-Servers Stratum-2-Ebene abfragt (GS-A_3942). Die in [gemSpec_Net#5.1] „NTP-Topologie“ getroffenen Anforderungen werden durch dieses Kapitel erweitert.

    Innerhalb des Zeitdienstes werden folgende Präfixe für Bezeichner verwendet:

    4.2.5.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4786

    Falls der Leistungsumfang Online nicht aktiviert ist (MGM_LU_ONLINE=Disabled), MUSS sichergestellt werden, dass der maximale zulässige Fehler von +/- 20ppm (part per million) gegenüber einer Referenzuhr nicht überschritten wird. Dies entspricht einer maximalen Abweichung im Freilauf von +/- 34,56 Sekunden über 20 Tage.

    <=

    TIP1-A_4787

    Der NTP-Server des Konnektors MUSS deaktiviert sein, falls der Konnektor Leistungsumfang Online nicht aktiviert ist (MGM_LU_ONLINE=Disabled.

    <=

    Falls die Systemzeit des Konnektors zu stark von der Zeit der zentralen TI-Plattform abweicht, deutet dies auf ein schwerwiegendes Problem im Konnektor oder der Umgebung hin, da dies im ordnungsgemäßen Betrieb nicht auftreten sollte.

    TIP1-A_4788

    Der Konnektor DARF die im Konnektor vorgehaltene Systemzeit im Rahmen einer automatisierten Synchronisation NICHT aktualisieren, wenn die lokale Zeit von der im Rahmen der Synchronisation erhaltenen Zeit um mehr als NTP_MAX_TIMEDIFFERENCE abweicht. Dies betrifft NICHT Änderungen in der Darstellung der Systemzeit, die zeitzonenbedingt sind (MEZ -> MESZ -> MEZ), da die Zeitsynchronisation grundsätzlich UTC berücksichtigt. Bei einer erstmaligen Synchronisierung nach dem Boot-Vorgang oder bei einer erstmaligen Synchronisierung bei der Inbetriebnahme des Konnektors darf eine Synchronisation trotz einer Zeitabweichung größer einer Stunde durchgeführt werden. Daher MUSS der Konnektor bei einer Abweichung von mehr als einer Stunde in den kritischen Betriebszustand EC_TIME_DIFFERENCE_INTOLERABLE übergehen, ein weiterer fachlicher Betrieb des Konnektors DARF NICHT mehr erfolgen.

    <=

    Der kritische Betriebszustand kann anschließend über einen manuellen Eingriff (z. B. Reboot) behoben werden (siehe 3.3 Betriebszustand).

    TIP1-A_4789

    TAB_KON_640 listet die zu verwendenden Zustandsvariablen des Konnektor NTP-Servers. Diese Werte DÜRFEN NICHT durch den Administrator geändert werden.

    Tabelle 336: TAB_KON_640 Zustandswerte für Konnektor NTP-Server

    ReferenzID
    Belegung
    Zustandswerte
    NTP_WARN_PERIOD
    30
    Anzahl an Tagen nach der ersten erfolglosen Zeitsynchronisierung nach der eine Warnung an den Betreiber erfolgen soll
    NTP_GRACE_PERIOD
    50
    Anzahl an Tagen nach der ersten erfolglosen Zeitsynchronisierung nach welcher der Konnektor in einen kritischen Betriebszustand übergehen muss.
    Dieser Parameter wirkt nur bei MGM_LU_ONLINE = Enabled.
    NTP_MAX_
    TIMEDIFFERENCE

    3600
    Maximale Zeitabweichung in Sekunden zwischen Systemzeit und Zeit des Stratum-2-Zeitservers zum Zeitpunkt der Zeitsynchronisierung.
    Dieser Parameter wirkt nur bei MGM_LU_ONLINE = Enabled.

    <=

    4.2.5.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.2.5.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.2.5.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.2.5.4.1 TUC_KON_351 “Liefere Systemzeit”

    TIP1-A_4790

    Der Konnektor MUSS den technischen Use Case TUC_KON_351 „Liefere Systemzeit“ umsetzen.

    Tabelle 337: TAB_KON_776 TUC_KON_351 „Liefere Systemzeit“

    Element
    Beschreibung
    Name
    TUC_KON_351 „Liefere Systemzeit”
    Beschreibung
    Der Konnektor MUSS die Systemzeit auf Anforderung an Fachmodule liefern können.
    Anwendungsumfeld
    Den Fachanwendungen ist die Systemzeit zu liefern.
    Eingangsanforderung
    Die Echtzeituhr des Konnektors wurde gemäß den geforderten Synchronisationsintervallen aktualisiert (bei MGM_LU_ONLINE=Enabled) oder manuell gesetzt (bei MGM_LU_ONLINE=Disabled)
    Auslöser und Vorbedingungen
    Fachmodule benötigen die aktuelle Systemzeit des Konnektors.
    Eingangsdaten
    Echtzeituhr des Konnektors
    Komponenten
    Konnektor, Fachmodule
    Ausgangsdaten
    Systemzeit des Konnektors
    Standardablauf
    Siehe [gemSpec_Net]
    Varianten/Alternativen
    Keine
    Fehlerfälle
    4178: Konnektor retourniert keine Systemzeit
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 338: TAB_KON_641 Fehlercodes TUC_KON_351 „Liefere Systemzeit“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4178
    Technical
    Error
    Das Fachmodul konnte die aktuelle Systemzeit des Konnektors nicht abrufen

    <=

    4.2.5.5 Operationen an der Außenschnittstelle
    4.2.5.5.1 Sync_Time

    TIP1-A_4791

    Der NTP-Server des Konnektors MUSS an der Client-Schnittstelle eine Operation sync_Time anbieten.

    Tabelle 339: TAB_KON_642 Operation sync_Time

    Name
    I_NTP_Time_Information:sync_Time
    Beschreibung
    Der Konnektor MUSS anfragenden Clients (z.B. Ärztearbeitsplatz) per NTP-Version 4 die Systemzeit liefern
    Aufrufparameter Vgl. [NTPv4]
    Rückgabe Vgl. [NTPv4]
    Vorbedingungen
    MGM_LU_ONLINE=Enabled
    Nachbedingungen
    Der anfragende Client hat die korrekte Zeit geliefert bekommen.
    Hinweise
    Keine
    Fehler
    Der Aufruf schlägt fehl (bleibt unbeantwortet), wenn MGM_LU_ONLINE=Disabled

    <=

    4.2.5.6 Betriebsaspekte

    TIP1-A_4792

    Der Konnektor MUSS dem Administrator die Möglichkeit bieten, eine Synchronisation mit dem zentralen Zeitdienst explizit anzustoßen.

    <=

    TIP1-A_4793

    Der Administrator MUSS die in TAB_KON_643 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_730 aufgelisteten Parameter ausschließlich einsehen können.

    Tabelle 340: TAB_KON_643 Konfiguration des Konnektor NTP-Servers

    ReferenzID
    Belegung
    Bedeutung
    NTP_TIMEZONE
    Zeitzone
    Der Administrator MUSS die Zeitzone des Konnektors einstellen können.
    Default-Wert: Central European Time/Mitteleuropäische Zeit (CET/MEZ)
    NTP_TIME
    Zeit
    Der Administrator MUSS die Zeit des Konnektors (NTP_TIME) über die Managementschnittstelle manuell einstellen können.

    Tabelle 341: TAB_KON_730 Einsehbare Konfigurationsparameter des Konnektor NTP-Servers

    ReferenzID
    Belegung
    Bedeutung
    NTP_SERVER_
    ADDR

    IP-Adressen
    Die Adressen des primären und sekundären Stratum-2-Zeitserver der zentralen TI-Plattform für die Synchronisation mit dem NTP-Server des Konnektors.

    <=

    TIP1-A_4794

    Befindet sich der Konnektor im Zustand EC_TIME_SYNC_PENDING_CRITICAL oder EC_Time_Difference_Intolerable, MUSS der Administrator eine Korrektur oder Bestätigung der Systemzeit vornehmen können. Anschließend MUSS der Konnektor wie nach einer erfolgreichen Zeitsynchronisation verfahren, d. h. der Tagezähler wird auf 0 zurückgesetzt.

    <=

    4.2.5.6.1 TUC_KON_352 Initialisierung Zeitdienst

    TIP1-A_4795

    Der Konnektor MUSS in der Bootup-Phase TUC_KON_352 "Initialisierung Zeitdienst" durchlaufen.

    Tabelle 342: TAB_KON_644 – TUC_KON_352 „Initialisierung Zeitdienst“

    Element
    Beschreibung
    Name
    TUC_KON_352 „Initialisierung Zeitdienst“
    Beschreibung
    Der Konnektor muss zum Bootup den konnektoreigenen NTP-Server mit einem NTP-Server der zentralen TI-Plattform synchronisieren falls MGM_LU_ONLINE=Enabled.
    Anwendungsumfeld
    Synchronisierung der Systemzeit zur Startzeit
    Eingangsanforderung
    Keine
    Auslöser
    • Bootup
    • Event NETWORK/VPN_TI/UP
    Vorbedingungen
    Verbindung zum VPN-Konzentrator TI muss aufgebaut sein
    Eingangsdaten
    NTP-Server der zentralen TI-Plattform
    Komponenten
    Konnektor
    Ausgangsdaten
    Keine
    Standardablauf
    Falls MGM_LU_ONLINE=Enabled:
    •        Durch eine DNS-Anfrage an den DNS-Forwarder zur Auflösung des SRV-RR mit dem Bezeichner "_ntp._udp.<DOMAIN_SRVZONE_TI>„ erhält der Konnektor Adressen der NTP-Server der zentralen TI-Plattform.
    •        gemäß [NTPv4]
    •        Falls keine Antwort erfolgt ist oder falls der Zeitserver nicht erreichbar ist, wird Fehler 4177 ausgelöst. Zur Feststellung werden die NTPv4 eigenen Timeoutwerte berücksichtigt.
    Varianten/Alternativen
    Keine
    Fehlerfälle
    4177: Der NTP-Server des Konnektors empfängt keine Systemzeit
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 343: TAB_KON_645 Fehlercodes TUC_KON_352 „Initialisierung Zeitdienst“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    4177
    Technical
    Warning
    Der NTP-Server des Konnektors konnte nicht synchronisiert werden.

    <=

    4.2.6 Namensdienst und Dienstlokalisierung

    Innerhalb des Namensdienstes werden folgende Präfixe für Bezeichner verwendet:

    4.2.6.1 Funktionsmerkmalweite Aspekte

    TIP1-A_4796

    Der Konnektor MUSS einen Recursive Caching Nameserver zur Auflösung von DNS-Anfragen sowie einen autoritativen Nameserver zur Verwaltung der Zone „konlan.“ bereitstellen.
    Der Caching-Nameserver des Konnektors MUSS für Clientsysteme aus dem lokalen Netzwerk (ANLW_LAN_NETWORK_SEGMENT oder ANLW_LEKTR_INTRANET_ROUTES) erreichbar sein.
    Der Caching-Nameserver des Konnektors MUSS einen Timeout für die Bearbeitung von DNS-Abfragen beachten. Konnte eine DNS-Abfrage nicht durchgeführt werden, MUSS die Bearbeitung abgebrochen werden.
    <=

    TIP1-A_6480

    Der Konnektor MUSS in der Zone „konlan.“ die folgenden Resource Records bereitstellen:

    Die in spitzen Klammern angegebenen Werte müssen implementierungs- und konfigurationsabhängig vergeben werden.

    <=

    TIP1-A_4797

    Der DNS-Server des Konnektors MUSS die folgenden DNS-Forwards durchführen:

    Tabelle 344: TAB_KON_687 DNS-Forwards des DNS-Servers

    Domain
    Forwarders
    Bemerkungen
    Namensraum TI, *.DNS_TOP_
    LEVEL_DOMAIN_TI
    DNS_SERVERS_TI
    DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb des Namensraums der TI  mit der Top Level Domain telematik (für die PU) und telematik-test (für die RU und TU).
    Namensraum TI, Top Level Domain ti-wa (PU) und ti-wa-test (RU und TU). DNS_SERVERS_TI DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb des Namensraums der TI mit der Top Level Domain ti-wa (für die PU) und ti-wa-test (für die RU und TU).
    Namensraum angeschlossene Netze des Gesundheitswesens mit WANDA Basic
    (Domainnamen
    von angeschlossenen Netzen des Gesundheitswesens mit WANDA Basic gemäß
    Bestandsnetze.xml)
    DNS_
    SERVERS_
    BESTANDS
    NETZE
    (Je Domainnamen eines angeschlossenen Netzes des Gesundheitswesens mit WANDA Basic alle zugehörigen DNS-Server IP-Adressen gemäß Bestandsnetze.xml)
    Je angeschlossenes Netz des Gesundheitswesens mit WANDA Basic in ANLW_AKTIVE_BESTANDSNETZE wird eine DNS Forward Rule zur Auflösung von DNS-Namen innerhalb dieses Netzes verwendet.
    Namensraum lokale Einsatzumgebung
    (DNS_DOMAIN_
    LEKTR)
    DNS_
    SERVERS_
    LEKTR
    DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb der DNS-Domain DNS_DOMAIN_LEKTR
    Namensraum
    Internet
    DNS_
    SERVERS_
    SIS
    Wenn der VPN-Tunnel SIS aktiv ist, muss eine Forward Rule für den Namensraum Internet über die DNS_SERVERS_SIS existieren.
    Namensraum
    Internet
    DNS_
    SERVERS_
    INT
    Wenn der VPN-Tunnel SIS nicht aktiv ist, muss eine Forward Rule für den Namensraum Internet über die DNS_SERVERS_INT existieren
    Lokale Zone
    „konlan.“
    autoritativer Nameserver des Konnektors
    DNS Forward Rule zur Auflösung aller DNS-Namen innerhalb der Zone „konlan.“

    <=

    TIP1-A_4798

    Der Stub-Resolver im Konnektor MUSS von allen internen Diensten zur Namensauflösung genutzt werden.

    Der Stub-Resolver im Konnektor MUSS immer den Caching-Nameserver im Konnektor anfragen.

    <=

    TIP1-A_4799

    Der Konnektor, der einen Caching Nameserver als Validating Resolver umsetzt, MUSS den DNSSEC-Vertrauensanker der TI aus dem Zertifikatspeicher in den Caching-Nameserver übernehmen, wenn ein Fehler bei der Validierung der Namensauflösung der TI aufgetreten ist. <=

    4.2.6.2 Durch Ereignisse ausgelöste Reaktionen

    Keine.

    4.2.6.3 Interne TUCs, nicht durch Fachmodule nutzbar

    Keine.

    4.2.6.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.2.6.4.1 TUC_KON_361 „DNS-Namen auflösen“

    TIP1-A_4801

    Der Konnektor MUSS den technischen Use Case TUC_KON_361 „DNS-Namen auflösen“ umsetzen.

    Tabelle 345: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“

    Element
    Beschreibung
    Name
    TUC_KON_361 „DNS-Namen auflösen“
    Beschreibung
    Ein FQDN wird in ein oder mehrere IPs aufgelöst
    Auslöser
    interne Anfrage (Basisdienst oder Fachmodul)
    Vorbedingungen
    Die vom Konnektor zu verwendenden DNS-Server (DNS_SERVERS_INT, DNS_SERVERS_TI, DNS_SERVERS_SIS, DNS_SERVERS_BESTANDSNETZE) müssen konfiguriert sein.
    Eingangsdaten
    FQDN (Name, für den die IP-Adressen ermittelt werden sollen)
    Komponenten
    Konnektor
    Ausgangsdaten
    LIST_OF_IP_ADDRESSES
    Standardablauf
    1) Mit dem FQDN wird eine Anfrage an den Stub-Resolver des Konnektors (Typ A und AAAA) durchgeführt.
    Für alle ermittelten IPv4-Adressen und IPv6-Adressen werden als LIST_OF_IP_ADDRESSES zurückgeliefert.
    Da IPv6 nicht produktiv eingesetzt wird muss die aufrufende Instanz die IPv6-Adressen ignorieren.
    Falls keine IP-Adressen ermittelt werden konnten, wird eine leere Liste zurückgeliefert.
    Varianten/Alternativen
    Keine
    Fehlerfälle
    ( 1) Timeout der Anfrage; Fehlercode 4179
    ( 1) DNS-Fehler; Fehlercode 4180
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 346: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4179
    Technical
    Error
    „DNS: Anfrage wurde wegen Timeout abgebrochen.”
    4180
    Technical
    Fatal
    „DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“
    Die Fehlerdetails sind gemäß DNS-Protokoll zu ergänzen.

    <=

    TIP1-A_4801-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_361 „DNS-Namen auflösen“ umsetzen.

    Tabelle 347: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“

    Element
    Beschreibung
    Name
    TUC_KON_361 „DNS-Namen auflösen“
    Beschreibung
    Ein FQDN wird in ein oder mehrere IPs aufgelöst
    Auslöser
    interne Anfrage (Basisdienst oder Fachmodul)
    Vorbedingungen
    Die vom Konnektor zu verwendenden DNS-Server (DNS_SERVERS_INT, DNS_SERVERS_TI, DNS_SERVERS_SIS, DNS_SERVERS_BESTANDSNETZE) müssen konfiguriert sein.
    Eingangsdaten
    FQDN (Name, für den die IP-Adressen ermittelt werden sollen)
    Komponenten
    Konnektor
    Ausgangsdaten
    LIST_OF_IP_ADDRESSES
    Standardablauf
    1) Mit dem FQDN wird eine Anfrage an den Stub-Resolver des Konnektors (Typ A und AAAA) durchgeführt.
    Für alle ermittelten IPv4-Adressen und IPv6-Adressen werden als LIST_OF_IP_ADDRESSES zurückgeliefert.
    Wird IPv6 nicht produktiv eingesetzt, muss die aufrufende Instanz die IPv6-Adressen ignorieren.
    Falls keine IP-Adressen ermittelt werden konnten, wird eine leere Liste zurückgeliefert.
    Varianten/Alternativen
    Keine
    Fehlerfälle
    ( 1) Timeout der Anfrage; Fehlercode 4179
    ( 1) DNS-Fehler; Fehlercode 4180
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 348: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4179
    Technical
    Error
    „DNS: Anfrage wurde wegen Timeout abgebrochen.”
    4180
    Technical
    Fatal
    „DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“
    Die Fehlerdetails sind gemäß DNS-Protokoll zu ergänzen.

    <=

    4.2.6.4.2 TUC_KON_362 „Liste der Dienste abrufen“

    TIP1-A_4802

    Der Konnektor MUSS den technischen Use Case TUC_KON_362 „Liste der Dienste abrufen“ umsetzen.

    Tabelle 349: TAB_KON_648 – TUC_KON_362 „Liste der Dienste abrufen“

    Element
    Beschreibung
    Name
    TUC_KON_362 „Liste der Dienste abrufen“
    Beschreibung
    Ermittlung aller zu einer DNS-SD-Gruppe gehörenden DNS-Namen.
    Auslöser
    interne Anfrage (Basisdienst oder Fachmodul)
    Vorbedingungen
    Die vom Konnektor zu verwendenden DNS-Server müssen konfiguriert sein.
    Eingangsdaten
    FQDN des PTR Resource Records
    Komponenten
    Konnektor
    Ausgangsdaten
    LIST_OF_SRV_ENTITIES
    Standardablauf
    Mit dem FQDN wird eine Typ „PTR“ Anfrage an den Stub-Resolver des Konnektor gestellt.
    Varianten/Alternativen
    Keine
    Fehlerfälle
    ( 1) Timeout der Anfrage; Fehlercode 4179
    ( 1) DNS-Fehler; Fehlercode 4180
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine


    Tabelle 350: TAB_KON_649 Fehlercodes TUC_KON_362 „Liste der Dienste abrufen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4179
    Technical
    Error
    „DNS: Anfrage wurde wegen Timeout abgebrochen.”
    4180
    Technical
    Fatal
    „DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“
    Die Fehlerdetails sind gemäß [gemSpec_Net] zu ergänzen.


    <=

    4.2.6.4.3 TUC_KON_363 „Dienstdetails abrufen“

    TIP1-A_4803

    Der Konnektor MUSS den technischen Use Case TUC_KON_363 „Dienstdetails abrufen“ umsetzen.

    Tabelle 351: TAB_KON_650 - TUC_KON_363 „Dienstdetails abrufen“

    Element
    Beschreibung
    Name
    TUC_KON_363 Dienstdetails abrufen
    Beschreibung
    Ermitteln aller DNS-SD-Details zu einem vollqualifizierten DNS-Namen.
    Auslöser
    interne Anfrage (Basisdienst oder Fachmodul)
    Vorbedingungen
    Die vom Konnektor zu verwendenden DNS-Server müssen konfiguriert sein.
    Eingangsdaten
    FQDN (der Name eines DNS-SD-Elements)
    Komponenten
    Konnektor
    Ausgangsdaten
    LIST_OF_SRV_ENTRIES
    LIST_OF_SRV_DETAILS
    Standardablauf
    1) Mit dem FQDN wird eine Typ-„SRV“-Anfrage an den Stub-Resolver des Konnektors gestellt.
    Die vom DNS-Server zurück gelieferten SRV-Einträge werden als LIST_OF_SRV_ENTRIES (bestehend aus TTL, Priority, Weight, Port, Target) zurückgeliefert.
    Wenn kein Eintrag gefunden werden konnte, wird eine leere Liste LIST_OF_SRV_ENTRIES zurückgeliefert.
    2) Mit dem FQDN wird zusätzlich eine Typ-„TXT“-Anfrage an den Stub-Resolver des Konnektors gestellt.
    Wenn ein oder mehrere entsprechende Einträge gefunden werden konnten, werden diese in einer gemeinsamen Liste
    LIST_OF_SRV_DETAILS (bestehend aus TTL und TXT) zusammengefasst.
    Wenn kein Eintrag gefunden werden konnte, wird eine leere Liste LIST_OF_SRV_DETAILS zurückgeliefert.
    Falls keine FQDN ermittelt werden konnten, wird je eine leere Liste LIST_OF_SRV_ENTRIES und LIST_OF_SRV_DETAILS zurückgeliefert.
    Varianten/Alternativen
    Keine
    Fehlerfälle
    ( 1-2) Timeout der Anfrage; Fehlercode 4179
    ( 1-2) DNS Fehler; Fehlercode 4180
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 352: TAB_KON_651 Fehlercodes TUC_KON_363 „Dienstdetails abrufen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4179
    Technical
    Error
    „DNS: Anfrage wurde wegen Timeout abgebrochen.”
    4180
    Technical
    Fatal
    „DNS: Es ist ein Fehler bei der Namensauflösung aufgetreten“
    Die Fehlerdetails sind gemäß [gemSpec_Net] zu ergänzen.

    <=

    4.2.6.5 Operationen an der Außenschnittstelle

    TIP1-A_4804

    Der Konnektor MUSS für Clients eine Basisanwendung Namensdienst anbieten.

    Tabelle 353: TAB_KON_652 Basisanwendung Namensdienst

    Name
    Namendienst
    Version
    wird im Produktsteckbrief des Konnektors definiert
    Namensraum
    Keiner
    Namensraum-Kürzel
    Keiner
    Operationen
    Name
    Kurzbeschreibung
    GetIPAddress
    Diese Operation ermöglicht die Auflösung von FQDNs in IP-Adressen
    WSDL
    Keines
    Schema
    Keines

    <=

    4.2.6.5.1 GetIPAddress

    TIP1-A_5035

    Der Namensdienst des Konnektors MUSS an der Client-Schnittstelle eine Operation GetIPAddress anbieten.

    Tabelle 354: TAB_KON_653 Operation GetIPAddress

    Name
    GetIPAddress
    Beschreibung
    Diese Operation ermöglicht die Auflösung von FQDN in IP-Adressen.
    (DNS-Forwarder Abfrage ohne Cache)
    Aufrufparameter
    Address (FQDN)
    DNSSECValidation (Boolean)
    Rückgabe
    IPAddr (IPAddress)
    DNSSECValidated (Boolean)
    Vorbedingungen
    Der DNS-Server im Konnektor muss aktiv sein.
    Die Forward Nameserver (DNS_SERVERS_TI, DNS_SERVERS_SIS, DNS_SERVERS_BESTANDSNETZE) müssen konfiguriert sein.
    Nachbedingungen
    Keine
    Standardablauf
    Für Details zu DNS Namensauflösung wird auf [gemSpec_Net] verweisen.

    <=

    4.2.6.6 Betriebsaspekte

    TIP1-A_5416

    Der Konnektor MUSS in der Bootup-Phase zur Initialisierung des Funktionsmerkmals „Namensdienst und Dienstlokalisierung:

    <=

    TIP1-A_4805

    Der Administrator MUSS die in TAB_KON_654 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_731 aufgelisteten Parameter ausschließlich einsehen können.
    Nach jeder Änderung MUSS sichergestellt werden, dass die Änderungen sofort am autoritativen bzw. am Caching-Nameserver zur Verfügung stehen.

    Tabelle 355: TAB_KON_654 - Konfigurationsparameter Namensdienst

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    DNS_SERVERS_INT

    Liste von IP-Adressen der DNS-Server

    Liste von DNS-Servern für das Transportnetz.
    Die IP-Adressen KÖNNEN auf einen öffentlich zugänglichen Adressbereich eingeschränkt sein.
    DNS_DOMAIN_
    VPN_ZUGD_INT

    DNS Domainname

    DNS-Domainname für die Service Discovery der VPN-Konzentratoren des VPN-Zugangsdienstes
    DNS_SERVERS_
    LEKTR

    Liste von IP-Adressen der DNS-Server

    Liste von DNS-Servern, die zur Namensauflösung von Namensräumen in der Einsatzumgebung verwendet werden.
    Der Administrator MUSS die Liste von DNS-Servern, die die DNS_DOMAIN_LEKTR auflösen, bearbeiten können.
    Die IP-Adressen der DNS-Server KÖNNEN auf den Adressbereich der ANLW_LAN_IP_ADDRESS eingeschränkt sein.
    DNS_DOMAIN_
    LEKTR

    DNS Domainname

    DNS Domainname, der von einem DNS-Server der Einsatzumgebung aufgelöst wird. Der Name DARF NICHT mit einem „.“ beginnen und nicht mit einem „.“ enden.
    DNS_TA_CONFIG

    Ist abhängig von der gewählten Umsetzung

    Wenn der Konnektor als Validating Resolver für den Namensraum Internet implementiert ist gilt:
    Der Administrator MUSS die aktuellen DNSSEC Trustanchor für den Namensraum Internet auf geeignetem Weg in den Konnektor übernehmen können.

    Tabelle 356: TAB_KON_731 Einsehbare Konfigurationsparameter Namensdienst

    ReferenzID
    Belegung
    Bedeutung
    DNS_SERVERS_TI

    Liste von IP-Adressen der DNS-Server

    Liste von DNS-Servern, die zur Namensauflösung des Namensraums der TI verwendet werden
    DNS_SERVERS_SIS

    Liste von IP-Adressen der DNS-Server

    Liste von DNS-Servern, die zur Namensauflösung des Namensraums Internet bei Nutzung des SIS verwendet werden
    DNS_SERVERS_
    BESTANDSNETZE

    Liste von IP-Adressen der DNS-Servern je Domäne je freigegebenem angeschlossenen Netz des Gesundheitswesens mit WANDA Basic
    Liste von DNS-Servern je Domain eines dieser freigegebenen Netze.

    DNS_TOP_LEVEL_
    DOMAIN_TI
    DNS Domainname

    Top Level Domain des Namensraumes TI
    <=

    4.2.7 Optionale Verwendung von IPv6

    Der Konnektor kann zusätzlich eine IPv6-Adresse an den Netzwerkschnittstellen zum Transportnetz implementieren. Entscheidet sich der Hersteller für den parallelen Einsatz von IPv4 und IPv6 (Dual-Stack-Mode), sind die nachfolgenden Anforderungen dieses Kapitels umzusetzen. Einhergehend mit der Entscheidung, IPv6 an diesem Interface zu konfigurieren, ist der spätere VPN-Tunnelaufbau zur TI und SIS über das IPv6 Interface möglich. Die durch den jeweiligen IPv6-Tunnel zu transportierenden IP-Pakete sind IPv4 adressierte Pakete.

    A_17199

    Der Konnektor MUSS bei Verwendung von IPv6 für den VPN-Tunnelaufbau zur TI und SIS auf geeignete Weise (z.B. DHCP vom IAG) mit einer IPv6-Adresse auf dem physikalischen Interface in Richtung Internet konfiguriert werden (Dual-Stack-Mode). <=

    A_17200

    Der Konnektor MUSS bei Verwendung von IPv6 für den VPN-Tunnelaufbau zur TI und SIS die Fragmentierung von IKEv2 Nachrichten gemäß [RFC7383] unterstützen. <=

    A_17201

    Der Konnektor MUSS bei Verwendung von IPv6 für den VPN-Tunnelaufbau zur TI und SIS die notwendige Route für das Erreichen des Internets bereitstellen. <=

    4.3 Konnektormanagement

    Das Konnektormanagement dient ausschließlich Betriebsaspekten des Konnektors. Daher wird in diesem Kapitel weitestgehend auf die übliche Strukturierung nach TUCs (intern/für Fachmodule), Außenoperationen und Betriebsaspekten verzichtet. Lediglich der KSR-Client verwendet diese Kapitelstruktur.

    Innerhalb des Konnektormanagements werden vorrangig folgende Präfixe für Bezeichner verwendet:

    Eine Ausnahme hiervon bildet der Anteil der Software-Aktualisierung (KSR-Client). Dieser verwendet folgende Präfixe für Bezeichner:

    TIP1-A_4806

    Der Konnektor MUSS LAN-seitig über eine Managementschnittstelle für Konfiguration und Diagnose verfügen.
    Die Ausführung der Schnittstelle ist herstellerspezifisch, MUSS aber entweder als Konfigurations-Frontend im Sinne einer eigenständigen Client-Applikation oder als Web-Oberfläche ausgeprägt sein.
    Wenn die Schnittstelle als Web-Oberfläche ausgeprägt ist, MUSS im Handbuch beschrieben sein, wo angegeben ist, welche Browser-Versionen für welche Betriebssysteme unterstützt werden (bspw. im Handbuch selbst oder über einen Link auf eine Web-Seite des Herstellers), und wo diese als installierbares Softwarepaket oder direkt ausführbare Datei bezogen werden können.
    Die Verbindung zur Managementschnittstelle MUSS zur Sicherung der Vertraulichkeit, Integrität und Authentizität durch Nutzung eines kryptographischen Verfahrens gemäß [gemSpec_Krypt] abgesichert werden, falls die Sicherheit der übertragenen Daten nicht auf andere Weise erreicht wird. Die Absicherung der Daten kann z. B. durch Nutzung von TLS unter Berücksichtigung der in [gemSpec_Krypt] angegebenen Algorithmen und Schlüssellängen geschehen.
    Die Managementschnittstelle MUSS in thematisch gegliederte Konfigurationsbereiche unterteilt sein. Die konkrete Gliederung selbst ist herstellerspezifisch.
    Die Managementschnittstelle KANN einen Managementbereich aufweisen, der nur für autorisierte Techniker des Herstellers zugänglich ist. Ein Zugriff auf diesen Bereich MUSS durch eine eigene Authentisierungsfunktion geschützt werden (z. B. durch Passwortschutz).
    <=

    Die über die Managementschnittstelle zu erreichenden und zu verändernden Inhalte werden erhoben in:

    Eine Ergänzung um weitere, herstellerspezifische Konfigurationsinhalte ist möglich.

    TIP1-A_5661

    Der Konnektor MUSS für die Automatisierung von Konnektor-Tests alle Funktionen, die über die Managementschnittstelle bereitgestellt werden, über eine LAN-seitige Schnittstelle ohne graphische Benutzerführung bereitstellen.

    Der Konnektorhersteller MUSS eine Dokumentation der Schnittstelle bereitstellen, welche die Nutzung so beschreibt, dass die Schnittstelle von der gematik in vollem Umfang genutzt werden kann. Die Dokumentation MUSS der gematik im Regelfall zwei Wochen vor Einreichung des Zulassungsobjekts bereitgestellt werden. Von diesem Regelfall KANN in Abstimmung mit der gematik abgewichen werden.

    Die Schnittstelle SOLL mittels JSON [RFC7159] bereitgestellt werden. Wenn die Bereitstellung nicht mittels JSON erfolgt, MUSS sie über eine vergleichbare Technologie erfolgen.

    Der Zugriff auf die Schnittstelle MUSS in RU/TU erlaubt sein. Falls der Zugriff in der PU erlaubt ist, MUSS er dort ebenso wie die Managementschnittstelle abgesichert sein:

    Ansonsten DARF der Zugriff in der PU NICHT möglich sein.

    <=

    TIP1-A_4807

    Das Management des Konnektors MUSS über die Managementschnittstelle mandantenübergreifend erfolgen. Dies bedeutet insbesondere, dass ein Administrator (gemäß seiner Zugriffsberechtigungen) in einer Management-Session alle Einstellungen einsehen und verändern können MUSS, egal welchem Mandanten diese Werte zugeordnet sind.

    <=

    TIP1-A_5658

    Der Konnektor MUSS die Managementschnittstelle mit zwei getrennten Endpunkten implementieren. Der Konnektor MUSS sicherstellen, dass auf den einen Endpunkt nur Nutzer mit der Rolle Lokaler-Administrator oder Super-Administrator zugreifen können, und auf den anderen Endpunkt nur Nutzer mit der Rolle Remote-Administrator.

    <=

    TIP1-A_5005

    Jede Änderung, die ein Administrator vornimmt, MUSS protokolliert werden durch TUC_KON_271 „Schreibe Protokolleintrag“ {
        topic=„MGM/ADMINCHANGES“;
        eventType=Op;
        severity=Info;
        parameters =(„User=$AdminUsername,
                               RefID=$ReferenzID,
                               NewVal=$NeuEingestellterWert“)}
    Der hier geforderte Logging-Level gilt, wenn nicht an anderer Stelle eine abweichende Regelung spezifiziert ist.
    Wenn die Änderung über ein Remote-Management-System durchgeführt wird, ohne dass ein Remote-Administrator im Konnektor konfiguriert ist, so MUSS als User eine Referenz auf das Remote-Management-System verwendet werden.
    Passwörter DÜRFEN NICHT in den Protokolleinträgen geschrieben werden.

    <=

    4.3.1 Zugang und Benutzerverwaltung des Konnektormanagements

    Der Konnektor verfügt über keine Verwaltung der fachlichen Nutzer, wohl aber über eine Verwaltung der Nutzer, die in der Rolle eines Administrators den Konnektor konfigurieren und die Protokolle einsehen dürfen. Dabei werden drei Administrator-Rollen unterschieden:

    1. Lokaler-Administrator: zur Konfiguration des Konnektors über die lokale Managementschnittstelle
    2. Remote-Administrator: zur Konfiguration des Konnektors über die remote Managementschnittstelle.
    3. Super-Administrator: zur Verwaltung von Benutzerkonten und zur Konfiguration des Konnektors über die lokale Managementschnittstelle

    TIP1-A_4808-01

    Der Konnektor MUSS sicherstellen, dass die Managementschnittstelle vor unberechtigtem Zugang geschützt ist. Die Managementschnittstelle MUSS durch eine Kombination aus Benutzername und Passwort oder einen mindestens gleich starken Mechanismus vor unberechtigtem Zugang geschützt sein.

    Für die Passworterstellung MUSS der Konnektor mindestens folgende Aspekte berücksichtigen:

    Für die Passwortverarbeitung MUSS der Konnektor mindestens folgende Aspekte berücksichtigen:
    <=

    Näheres hierzu regeln die Schutzprofile des Konnektors.

    TIP1-A_4810

    Der Konnektor MUSS eine Benutzerverwaltung für die Managementschnittstelle enthalten, in der anmeldeberechtigte Administratoren-Benutzer definiert werden können.
    Die Benutzerverwaltung MUSS die Administrator-Rollen Lokaler-Administrator, Remote-Administrator und Super-Administrator unterstützen.
    Den Administrator-Rollen MÜSSEN folgende Rechte zugewiesen sein:


    Tabelle 357: TAB_KON_655 Konfigurationen der Benutzerverwaltung (Super-Administrator)

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    MGM_USER_LIST
    Liste von Benutzernamen und deren Kontaktdaten
    Liste von Benutzern und deren Kontaktdaten.
    Benutzerkonten MÜSSEN angelegt, geändert und gelöscht werden können.
    Das Passwort eines Benutzerkontos MUSS neu gesetzt werden können.
    MGM_ADMIN
    _RIGHTS

    Liste von Zugriffsrechten eines Benutzers
    i. Eindeutige Zuordnung eines Benutzerkontos
      zu einer Rolle.
       Die Benutzerverwaltung MUSS sicherstellen,
      dass zu jeder Zeit mindestens ein
      Benutzerkonto mit der Rolle Super-
       Administrator vorhanden ist.
      Gewähren/Entziehen von Rechten für
       Benutzerkonten:
    ii. Zugriffsrechte bezüglich der
        Konfigurationsbereiche.
    iii. Recht zum Aufbau einer Remote-
        Manage
    ment-Session und/oder zur Konfiguration des Remote-Management gemäß TAB_KON_663 (USER_INIT_REMOTESESSION).
    iv. Recht für einen Werksreset
        (USER_RESET_PERMISSION)

    Die Benutzerverwaltung MUSS es jedem Benutzer ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_656 vorzunehmen:

    Tabelle 358: TAB_KON_656 Konfigurationen der Benutzerverwaltung

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    MGM_USER_INFO
    Kontaktdaten
    Der angemeldete Benutzer MUSS seine Kontaktdaten ändern können. Der Benutzername DARF NICHT änderbar sein.

    <=

    4.3.2 Konnektorname und Versionsinformationen

    TIP1-A_4811

    Der Konnektor MUSS die Konfiguration und Nutzung eines sprechenden Konnektornamens unterstützen, der identisch zum Hostnamen des Konnektors ist. Der Konnektorname MUSS dauerhaft an der Managementschnittstelle angezeigt werden.
    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_657 vorzunehmen:

    Tabelle 359: TAB_KON_657 Konfigurationsparameter des Konnektornamens

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    MGM_KONN_
    HOSTNAME

    12 Zeichen
    Der Konnektorname MUSS folgende Anforderungen erfüllen (in Anlehnung an die Definition eines „Labels“ in [RFC1034]):
    • Verwendung der Buchstaben „A bis Z“ und „a bis z“,
    Verwendung der Ziffern „0 bis 9“,
    • als Sonderzeichen „–“ (Minus), sowie
    • eine maximale Länge von 12 Zeichen,
    Die Verwendung weiterer Sonderzeichen sowie des Leerzeichens DARF NICHT möglich sein.
    Optional KANN ein Hersteller zusätzlich zum Konnektor- bzw. Hostnamen die Konfiguration eines DNS-Suffixes vorsehen. Der DNS-Suffix DARF NICHT Bestandteil des Konnektornamens sein.
    <=

    TIP1-A_4812

    Der Administrator MUSS die Versionsinformationen des Konnektors einsehen können. Dabei MÜSSEN alle über ProductInformation.xsd definierten Elemente verständlich angezeigt werden.
    Ferner MUSS der Administrator dabei die aktuelle Firmware-Gruppenversion des Konnektors einsehen können.
    <=

    A_18929

    Der Hersteller MUSS die ECC-Vorbereitung der gSMC-K durch die Bezeichnung „ECC-Vorbereitet“ zusammen mit den Versionsinformationen des Konnektors an der Managementschnittstelle sichtbar machen.
    <=

    TIP1-A_7255

    Der Administrator MUSS die Versionen der in der Firmware des Konnektors enthaltenen Fachmodule einsehen können.
    <=

    Fachmodulversionsinformationen sind nicht Bestandteil der Selbstauskunft gemäß ProductInformation.xsd.

    4.3.3 Konfigurationsdaten: Persistieren sowie Export-Import

    TIP1-A_4813

    Der Konnektor MUSS die Konfigurationsdaten nach Änderung persistieren. Dabei MÜSSEN Integrität, Authentizität und Vertraulichkeit der Konfigurationsdaten gewährt sein. Der Mechanismus hierfür ist herstellerspezifisch.
    Der Konnektor MUSS sicherstellen, dass immer ein integerer Konfigurationssatz persistiert ist.
    Bei der Konnektorinitialisierung MÜSSEN die persistierten Konfigurationsdaten eingelesen werden.
    Die Verpflichtung zur Persistierung gilt für alle innerhalb der Konnektor- und Fachmodul-Spezifikationen erhobenen Konfigurationsdaten.
    <=

    TIP1-A_4814

    Der Administrator MUSS die gesamten Konfigurationsdaten des Konnektors ex- und importieren können. Dazu gehören die Konfigurationsparameter des Konnektors, die persistenten Daten wie im Informationsmodell des Konnektors (Tabelle TAB_KON_507 Informationsmodell Entitäten) definiert  und die Pairing Informationen der Kartenterminals.
    Die Konfigurationsdaten des Anwendungs- und Netzkonnektors KÖNNEN gemeinsam oder getrennt exportiert bzw. importiert werden. Das Format der Konfigurationsdaten ist herstellerspezifisch.
    Auf hardwareseitig baugleichen Geräten:

    Der Import von Konfigurationsdateien, die von einem Konnektor mit anderer Hardwareversion exportiert wurden, KANN ermöglicht werden.

    (für Fachmodule siehe Kapitel 4.3.4)
    Der Konnektor MUSS sicherstellen, dass der Exportvorgang nur von einem am Konnektor angemeldeten User mit mindestens der Rolle Administrator ausgelöst werden kann.
    Der Konnektor MUSS sicherstellen, dass der Importvorgang nur von einem am Konnektor angemeldeten User mit der Rolle Super-Administrator ausgelöst werden kann.
    Sowohl Ex- als auch Import MÜSSEN protokolliert werden durch TUC_KON_271 „Schreibe Protokolleintrag“ {    
        topic = „MGM/CONFIG_EXIMPORT“;
        eventType = Op;
        severity = Info;
        parameters = („User=$AdminUsername,
                                Mode=[Export/Import]“)}.

    <=

    A_19738

    Der Konnektor KANN einem am Konnektor angemeldeten User mit der Rolle Lokaler-Administrator erlauben, den Importvorgang von Konfigurationsdateien auszulösen, wenn in den Konfigurationsdaten keine Benutzerdaten gemäß Tabelle TAB_KON_655 enthalten sind. <=

    Nähere Vorgaben zum Ablauf des Imports der Kartenterminalinformationen finden sich im Kapitel 4.1.4.6.3.

    TIP1-A_4815

    Die Integrität, Authentizität und Nichtabstreitbarkeit der exportierten Daten MUSS sichergestellt werden. Dies MUSS durch eine Signatur mit der OSIG-Identität der SM-B oder mit einem herstellerspezifischen Schlüsselpaar realisiert werden. In die zu signierenden Daten MUSS eine Zeitangabe zum Signaturzeitpunkt integriert werden. Beim Import MUSS die Signatur vor der Übernahme der Daten erfolgreich verifiziert worden sein. Im Laufe des Importvorgangs MUSS dem Administrator das zur Signatur zugehörige Zertifikat (oder der herstellerspezifische öffentliche Schlüssel) sowie die Zeitangabe zum Signaturzeitpunkt der exportierten Konfiguration angezeigt werden, und der Administrator MUSS explizit bestätigen, dass er die zu dem angezeigten Zeitpunkt gehörige Konfiguration importieren will.

    Wird die SM-B zur Signatur eingesetzt, so MUSS die Prüfung des genutzten Signaturzertifikats anhand von TUC_KON_037 erfolgen. Das Zertifikat der OSIG-Identität, mit dem die Daten signiert wurden, MUSS zusammen mit den exportierten Daten gespeichert werden, um eine Verifikation der Signatur auf neuen Konnektoren auch ohne Zugriff auf die entsprechende SM-B zu ermöglichen.

    Da Konfigurationsdaten mit einem Schutzbedarf von mindestens „Hoch für Authentizität und Nichtabstreitbarkeit exportiert werden (z. B. Pairing-Geheimnisse (ShS.KT.AUT) der Kartenterminals), MUSS durch geeignete Maßnahmen sichergestellt werden, dass der Zugriff auf die Daten auf eine natürliche Person rückführbar ist. Dies kann organisatorisch (durch Einträge des Administrators in ein Betriebsführungs-Handbuch beim Nutzer) technisch (durch eine personenbezogene Administratorenverwaltung) oder äquivalent herstellerspezifisch erreicht werden.

    <=

    TIP1-A_4816

    Zum Schutz der Vertraulichkeit der exportierten Daten MÜSSEN die Daten vor dem Export verschlüsselt werden. Dies kann durch asymmetrische oder symmetrische Verschlüsselungsverfahren nach [gemSpec_Krypt] realisiert werden.

    Wird ein rein symmetrisches Verfahren eingesetzt, so MUSS als Mindestanforderung eine Passphrase einer Mindestlänge von 16 Zeichen (Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen) zur Verschlüsselung der Daten eingesetzt werden. Diese Passphrase MUSS dabei vom Konnektor zufällig generiert werden und aus einer Kombination von Buchstaben und Ziffern bestehen. Diese Passphrase MUSS dem Administrator anschließend angezeigt werden.

    <=

    4.3.4 Administration von Fachmodulen

    Die Konfiguration von Fachmodulen ist innerhalb der Managementschnittstelle des Konnektors von der Konfiguration der Plattformanteile des Konnektors logisch entkoppelt. Die Festlegungen, welche Konfigurationsparameter und welche zusätzlichen administrativen Funktionen für ein Fachmodul benötigt werden, werden in den jeweiligen Fachmodulspezifikationen getroffen. Der Konnektor muss aber für jedes Fachmodul hinsichtlich der Administrierbarkeit des Fachmoduls die folgende Basisfunktionalität zur Verfügung stellen:

    TIP1-A_4818

    Neben den Konfigurationsbereichen der Plattformanteile des Konnektors, MUSS die Managementschnittstelle auch die Konfiguration der im Konnektor enthaltenen Fachmodule unterstützen.

    Ein Administrator MUSS die in den Fachmodulspezifikationen enthaltenen Konfigurationsparameter ändern und die dort definierten Informationen einsehen können.

    Der Konnektor MUSS die Konfigurationsdaten von Fachmodulen nach deren Änderung persistieren, sowie bei einem Neustart eines Fachmoduls die Fachmodul-Konfigurationsdaten vor der Initialisierung des Fachmoduls einlesen.

    Die persistierten Fachmodulkonfigurationsdaten MÜSSEN ebenso wie die plattformeigenen Konfigurationsdaten hinsichtlich ihrer Integrität und Authentizität sowie ihrer Vertraulichkeit geschützt werden.

    Der Ex- und Import von Fachmodulkonfigurationen MUSS äquivalent zum Ex- und Import der Plattformanteile für den Administrator möglich sein (siehe 4.3.3). Die Konfigurationsdaten der Fachmodule KÖNNEN dabei in der Gesamt Export-Datei des Konnektors enthalten sein oder separat exportiert und importiert werden.

    <=

    TIP1-A_5484

    Der Konnektor MUSS den Fachmodulen die Möglichkeit bereitstellen, die in den Fachmodulspezifikationen gekennzeichneten Konfigurationsdaten persistent zu speichern, auszulesen und zu löschen. Je Fachmodul muss ein exklusiv durch das Fachmodul nutzbarer Speicherbereich verwendet werden.
    Namenskonvention zur Kennzeichnung der Konfigurationsdaten der Fachmodule für persistent zu speichernde Daten:
    FM_<fmName>_<fmDataName>

    Tabelle 360: TAB_KON_833 Bezeichner für persistente Konfigurationsdaten für Fachmodule

    Bezeichner
    Bedeutung
    FM
    fester Namensbestandteil zur Kennzeichnung von persistenten fachmodulspezifischen Konfigurationsdaten
    _
    Trennzeichen
    <fmName>
    Name des Fachmoduls (innerhalb eines Fachmoduls konstanter Bezeichner)
    _
    Trennzeichen
    <fmDataName>
    Name der persistent zu speichernden fachmodulspezifischen Konfigurationsdaten

    <=

    4.3.5 Neustart und Werksreset

    TIP1-A_4819

    Der Administrator MUSS einen Neustart des Konnektors auslösen können.

    <=

    TIP1-A_4820

    Ein Administrator mit USER_RESET_PERMISSION MUSS einen Werksreset des Konnektors auslösen können.
    Zur Durchführung des Werksreset MUSS der Administrator nach Funktionsaufruf per Sicherheitsabfrage zur Bestätigung des Werksresets aufgefordert werden. Nach bestätigter Sicherheitsabfrage MUSS der Konnektor die gesamte Konfiguration des Konnektors und alle internen Speicher, mit Ausnahme des aktuellen Vertrauensraums sowie der Sicherheitsprotokolle und der installierten Firmware, auf den Auslieferungszustand zurücksetzen. Die in CERT_IMPORTED_CA_LIST enthaltenen Zertifikate MÜSSEN aus dem aktuellen Vertrauensraum gelöscht werden.
    Die Durchführung des Werksresets MUSS protokolliert werden durch TUC_KON_271 „Schreibe Protokolleintrag“ {
        topic = „MGM/FACTORYSETTINGS“;
        eventType = Op;
        severity = Info;
        parameters = „User=$AdminUsername“}.
    Dieser Protokolleintrag DARF NICHT durch einen erfolgreichen Werksreset verloren gehen.
    Der Hersteller MUSS ferner einen alternativen, herstellerspezifischen Weg zum Auslösen des Werksresets vorsehen, welcher die Arbeitsabläufe beim Nutzer nur minimal unterbricht. Auch für diesen zusätzlichen Weg MUSS zuvor eine Authentisierung durch eine Kombination aus Benutzername und Passwort oder einem mindestens gleich starken Mechanismus erfolgen. Der Mechanismus MUSS auch dann funktionieren, wenn sich keiner der in der Benutzerverwaltung definierten Administratoren mehr erfolgreichen anmelden kann.

    <=

    4.3.6 Leistungsumfänge und Standalone-Szenarios

    Obgleich der Konnektor in seinem Auslieferungszustand alle Leistungsmerkmale aufweisen muss, die gemäß Produkttypssteckbrief gefordert werden, so soll es dem Administrator doch ermöglicht werden grundsätzliche Leistungsumfänge gezielt deaktivieren zu können, um den Konnektor so besser in die organisatorische/technische Struktur der Betriebsstätte eingliedern zu können.

    TIP1-A_4821-02

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_658 vorzunehmen:

    Tabelle 361: TAB_KON_658 Aktivieren/Deaktivieren von Leistungsumfängen

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    MGM_LU_ONLINE
    Enabled/
    Disabled

    Der Administrator MUSS den „Leistungsumfang Online“ aktivieren und deaktivieren können.
    Bei Veränderung MUSS TUC_KON_256 gerufen werden {
      topic = „MGM/
    LU_CHANGED/LU_ONLINE“;
      eventType = Op;
      severity = Info;
      parameters = „Active=$MGM_LU_ONLINE“}

    MGM_LU_SAK
    Enabled/
    Disabled

    Der Administrator MUSS den „Leistungsumfang Signaturanwendungskomponente“ aktivieren und deaktivieren können.
    Default-Wert: Enabled
    Bei Veränderung MUSS TUC_KON_256 gerufen werden {
      topic = „MGM/
    LU_CHANGED/LU_SAK“;
      eventType = Op;
      severity = Info;
      parameters = „Active=$MGM_LU_SAK“}

    <=

    Der Konfigurationsparameter MGM_LU_SAK wirkt hauptsächlich in dem Funktionsmerkmal „Signaturdienst“ (siehe Kapitel 4.1.8).

    Ist MGM_LU_ONLINE Disabled, so baut der Konnektor grundsätzlich keine Online-Verbindungen auf (weder zur TI, noch zum SIS). Der Parameter wirkt hauptsächlich in den Funktionsmerkmalen:

    Ob es sich bei einem Konnektor um den losgelöst (stand alone) vom Netz der Einsatzumgebung betriebenen handelt, also einen Konnektor, auf welchen kein Clientsystem zugreift, muss diesem mitgeteilt werden:

    TIP1-A_4822

    Die Managementschnittstelle MUSS es einem Administrator ermöglichen Konfigurationsänderungen gemäß Tabelle TAB_KON_659 vorzunehmen:

    Tabelle 362: TAB_KON_659 Konnektor Standalone einsetzen

    ReferenzID

    Belegung

    Bedeutung und Administrator-Interaktion

    MGM_STANDALONE _KON

    Enabled/
    Disabled

    Der Administrator MUSS den Konnektor als alleinstehend konfigurieren können.
    Default-Wert: Disabled
    Bei Veränderung MUSS TUC_KON_256 gerufen werden {
      topic = „MGM/STANDALONE_CHANGED“;
      eventType = Op;
      severity = Info;
      parameters = „Active=$MGM_STANDALONE_KON“}


    ​​

    <=

    Das Setzen von MGM_STANDALONE_KON auf Enabled dient dem Konnektor als Anzeige, dass dieser ohne angeschlossenes Clientsystem (Primärsystem) betrieben wird. Diese Information kann seitens der Fachmodule verwendet werden, damit diese sich im Standalone-Fall anders als im Normalfall verhalten.

    4.3.7 Online-Anbindung verwalten

    Um Zugang zur TI erlangen zu können, muss der Betriebsstättenverantwortliche einen Vertrag mit einem Zugangsdienstprovider (ZGDP) abgeschlossen haben. Von diesem erhält er eine ContractID. Der Administrator muss den Konnektor (genauer das NK-Zertifikat C.NK.VPN) mit dieser Information unter Nutzung einer SM-B über den Registrierungsdienst des ZGDP bei diesem freischalten.

    Die Berechtigung zur Einwahl in die TI ist von der Gültigkeit der beiden bei der Freischaltung übermittelten Zertifikate abhängig (C.NK.VPN und C.HCI.OSIG). Die Berechtigung zur Einwahl in die TI wird verweigert, bzw. eine bestehende Verbindung zur TI wird beendet, wenn ein Zertifikat abgelaufen oder gesperrt ist. Aus diesem Grund muss der Administrator vor Ablauf eines der beiden Zertifikate eine wiederholte Registrierung mit neuem Netzkonnektorzertifikat bzw. neuer SM-B beim ZGDP durchführen. (Hinweis: neue NK-Zertifikate werden erst mit Etablierung der Nachladefunktionalität für gSMC-K verfügbar sein.)

    Soll ein Konnektor außer Betrieb genommen werden oder wird der Vertrag mit einem ZGDP gekündigt, muss der Administrator den Konnektor über den Registrierungsdienst des ZGDP abmelden.

    TIP1-A_4824

    Der Administrator MUSS die in TAB_KON_661 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_732 aufgelisteten Parameter ausschließlich einsehen können.

    Tabelle 363: TAB_KON_661 Konfigurationsparameter der Konnektorfreischaltung

    ReferenzID

    Belegung

    Bedeutung und Administrator-Interaktion

    MGM_ZGDP_
    CONTRACTID

    String

    Der Administrator MUSS die vom Zugangsdienstprovider für die Freischaltung des Konnektors erhaltene ContractID eingeben können.

    MGM_ZGDP_
    SMCB

    ICCSN

    Der Administrator MUSS die zur Freischaltung zu verwendende SM-B aus der Liste der verwalteten SM-Bs auswählen können.

    Tabelle 364: TAB_KON_732 Einsehbare Konfigurationsparameter der Konnektorfreischaltung

    ReferenzID

    Belegung

    Bedeutung und Administrator-Interaktion

    MGM_ZGDP_
    REGSERVER

    URI

    URI des Registrierungsservers des Zugangsdienstproviders

    Den Zustand der Freischaltung verwaltet der Konnektor gemäß Tabelle TAB_KON_662 Zustandswerte der Konnektorfreischaltung.
    Im Auslieferungszustand MUSS MGM_TI_ACCESS_GRANTED=Disabled belegt sein.

    Tabelle 365: TAB_KON_662 Zustandswerte der Konnektorfreischaltung

    ReferenzID

    Belegung

    Zustandswerte

    MGM_TI_
    ACCESS_
    GRANTED

    Enabled/
    Disabled

    Status der Freischaltung des Konnektors:
    - Enabled: Konnektor wurde erfolgreich beim Zugangsdienstprovider freigeschaltet
    - Disabled: Freischaltung noch nicht erfolgt


    ​​

    <=

    TIP1-A_4825

    Der Administrator MUSS den Konnektor über folgenden Mechanismus zur Nutzung freischalten bzw. eine vorhandene Freischaltung mit einer neuen SM-B aktualisieren können (Voraussetzung ist eine korrekte Konfiguration aller für einen Online-Zugang erforderlicher Parameter):

    1. Der Konnektor MUSS eine registerKonnektorRequest-Struktur gemäß ProvisioningService.xsd [gemSpec_VPN_ZugD] erstellen und mit den entsprechenden Parametern befüllen (aktuelles Datum/Uhrzeit, C.NK.VPN, MGM_ ZGDP_CONTRACTID). Der Konnektor MUSS die Request-Nachricht mittels der ausgewählten SM-B (ID.HCI.OSIG von MGM_ZGDP_SMCB) im Element registerKonnektorRequest/Signature signieren und das SM-B-Zertifikat im Element X509Data ablegen.    
      Ist der nötige Sicherheitszustand für den privaten Schlüssel der SM-B nicht gesetzt, MUSS der Konnektor zur PIN-Verifikation an dem Kartenterminal auffordern, in dem die SM-B steckt.
    2. Der Konnektor ermittelt die URI des Registrierungsservers (MGM_ZGDP_REGSERVER) durch eine DNS-Anfrage nach dem SRV und TXT Resource Record „_regserver._tcp.<DNS_DOMAIN_VPN_ZUGD_INT>„
    3. Der Konnektor ruft unter Verwendung der erzeugten Request-Nachricht die in [gemSpec_VPN_ZugD#Tab_ZD_registerKonnektor] definierte Operation I_Registration_Service::registerKonnektor mit der Zieladresse MGM_ZGDP_REGSERVER auf.
    4. Der Konnektor zeigt dem Administrator den Inhalt von registerKonnektorResponse/AdditionalInformation und /Status an
    5. Der Response der Operation wird verarbeitet:
      1.           Setze MGM_TI_ACCESS_GRANTED auf     
        - Enabled, wenn /RegistrationStatus = „Registriert“    
        - Disabled, wenn /RegistrationStatus = „Nicht registriert“
      2.           Persistiere diese Zustandsinformation zusammen mit dem VPN:ContractStatus
      3.           Verteile das folgende interne Ereignis über TUC_KON_256 {
             topic = ”MGM/TI_ACCESS_GRANTED“;
             eventType = Op;
             severity = Info;
             parameters = „Active=$MGM_TI_ACCESS_GRANTED“;
             doDisp = false }
    Tritt während der Verarbeitungskette ein Fehler auf, so bricht die weitere Verarbeitung ab und der Administrator MUSS darüber geeignet informiert werden (u.a. Klartextanzeige des vom Registrierungsdienst gemeldeten Fehlers).
    Wenn eine Reregistrierung mit einer neuen SMC-B fehlschlägt (Request wird mit einem SOAP-Error beantwortet ) dann ist der Konnektor nicht registriert (MGM_TI_ACCESS_GRANTED = Disabled).
    <=

    TIP1-A_4826-01

    Der Administrator MUSS über die Managementschnittstelle den aktuellen Freischaltstatus einsehen können (MGM_TI_ACCESS_GRANTED). Ist der Konnektor aktuell freigeschaltet, so MÜSSEN der VPN:ContractStatus, die für die Freischaltung verwendete(n) SMC-B und die verwendeten C.NK.VPN-Zertifikate angezeigt werden (RSA und/oder ECC).
    <=

    Möchte ein Konnektoreigentümer das Gerät weiterveräußern oder vollständig außer Betrieb nehmen, so sollte er eine vorhandene Freischaltung zuvor rückgängig machen.

    TIP1-A_4827

    Ist MGM_TI_ACCESS_GRANTED=Enabled, dann MUSS der Administrator über die Managementschnittstelle des Konnektors die Freischaltung über den folgenden Mechanismus zurücknehmen können:

    1.     Der Administrator MUSS eine Sicherheitsabfrage zur Zurücknahme der Freischaltung bestätigen
    2.     Der Konnektor MUSS eine deRegisterKonnektorRequest-Struktur gemäß [gemSpec_VPN_ZugD] erstellen und mit den entsprechenden Parametern befüllen (aktuelles Datum/Uhrzeit, C.NK.VPN, MGM_ ZGDP_CONTRACTID)
    3.     Der Konnektor MUSS die Request-Nachricht mittels einer verfügbaren SM-B (ID.HCI.OSIG) im Element deRegisterKonnektorRequest/Signature signieren. (MGM_ ZGDP_SMCB ist zu bevorzugen, es kann aber auch jede andere SM-B verwendet werden)    
      Ist der nötige Sicherheitszustand für den privaten Schlüssel der SM-B nicht gesetzt, MUSS der Konnektor zur PIN-Verifikation an dem Kartenterminal auffordern, in dem die SM-B steckt.
    4.     Der Konnektor ermittelt die URI des Registrierungsservers (MGM_ZGDP_REGSERVER) durch eine DNS-Anfrage nach dem SRV und TXT Resource Record „_regserver._tcp.<DNS_DOMAIN_VPN_ZUGD_INT>„
    5.     Der Konnektor ruft unter Verwendung der erzeugten Request-Nachricht die in [gemSpec_VPN_ZugD#Tab_ZD_deregisterKonnektor] definierte Operation I_Registration_Service::deRegisterKonnektor mit der Zieladresse MGM_ZGDP_REGSERVER auf.
    6.     Der Konnektor zeigt dem Administrator den Inhalt von deregisterKonnektorResponse/AdditionalInformation /ContractStatus und /RegistrationStatus an
    7.     Der Response der Operation wird verarbeitet:
      1.          Setze MGM_TI_ACCESS_GRANTED auf     
        - Enabled, wenn /RegistrationStatus = „Registriert“    
        - Disabled, wenn /RegistrationStatus = „Nicht registriert“
      2.          Persistiere diese Zustandsinformation zusammen mit dem Zeitpunkt
      3.          Verteile das folgende interne Ereignis über TUC_KON_256:     {
             topic = ”MGM/TI_ACCESS_GRANTED“;    
             eventType = Op;
             severity = Info;
             parameters = „Active=$MGM_TI_ACCESS_GRANTED“;
             doDisp=false }
    Tritt während der Verarbeitungskette ein Fehler auf, so bricht die weitere Verarbeitung ab und der Administrator MUSS darüber geeignet informiert werden (u.a. Klartextanzeige des vom Registrierungsdienst gemeldeten Fehlers).
    Wenn eine Deregistrierung mit einer neuen SMC-B fehlschlägt (Request wird mit einem SOAP-Error beantwortet) dann ist der Konnektor weiterhin registriert (MGM_TI_ACCESS_GRANTED = Enabled).
    <=

    TIP1-A_5655

    Der Hersteller des Konnektors MUSS im Handbuch den Administrator darüber informieren, dass der Konnektor bei dauerhafter Außerbetriebnahme (z. B. Verkauf, Schenkung, Entsorgung) beim Zugangsdienstprovider deregistriert werden muss.

    <=

    A_23120

    Der Konnektor DARF die automatische Re-Registrierung mit seinem ECC-NK-Zertifikat NICHT öfter als einmal am Tag versuchen. <=

    A_23150

    Der Konnektor MUSS dem Administrator über den Mechanismus in TUC_KON_411 ermöglichen, den Konnektor zu registrieren bzw. eine vorhandene Registrierung zu aktualisieren. Dabei MUSS der Administrator das für die Registrierung zu verwendende NK-Zertifikat (RSA oder ECC) und die zu verwendende SMC-B auswählen können.
    <=

    A_23122

    Der Konnektor MUSS dem Administrator ermöglichen, die automatische Re-Registrierung mit dem ECC-NK-Zertifikat ein- und auszuschalten. Im Auslieferungszustand muss die automatische Re-Registrierung eingeschaltet sein. <=

    A_23121

    Der Konnektor MUSS dem Administrator ermöglichen, die Verwendung von ECC bei IPsec/IKE-Verbindungen ein- und auszuschalten. Die Verwendung von ECC darf nur eingeschaltet werden, wenn der Konnektor mit seinem ECC-NK-Zertifikat beim VPN-Zugangsdienst registriert ist. Die Verwendung von ECC darf nur ausgeschaltet werden, wenn der Konnektor mit seinem RSA-NK-Zertifikat beim VPN-Zugangsdienst registriert ist.
    Im eingeschalteten Zustand MUSS der Konnektor die Vorgaben in A_17125 umsetzen. Im ausgeschalteten Zustand MUSS der Konnektor die Vorgaben in GS-A_4382 umsetzen.
    <=

    A_23149

    Der Konnektor MUSS dem Administrator ermöglichen, die Verwendung von ECDSA-basierten Ciphersuiten bei TLS-Verbindungen ein- und auszuschalten. Im ausgeschalteten Zustand DARF der Konnektor ECDSA-basierte Ciphersuiten NICHT anbieten (Rolle TLS-Client) und NICHT auswählen (Rolle TLS-Server). Ebenfalls DARF der Konnektor dann NICHT während des TLS-Verbindungsaufbaus (genauer bei der Signatur der ephemeren (EC)DH-Schlüssel) mit ECDSA-basierten Zertifikaten bzw. deren privaten ECC-Schlüsselmaterial Daten authentisieren. <=

    Es können separate Konfigurationsschalter für einzelne TLS-Strecken umgesetzt werden.

    Es gelten darüber hinaus:

    4.3.8 Re-Registrierung des Konnektors mit weiterem NK-Zertifikat

    Eine Re-Registrierung eines Konnektors am VPN-Zugangsdienst mit einem neuen NK-Zertifikat wird im Rahmen der ECC-Migration der IPsec-Kommunikation zum VPN-Zugangsdienst mit einem ECC-Zertifikat notwendig

    A_22332-01

    Solange der Konnektor nur mit einem RSA-Zertifikat am VPN-Zugangsdienst registriert ist, MUSS er mindestens einmal wöchentlich die Re-Registrierung mit seinem ECC-NK-Zertifikat beim Registrierungsdienst durchführen. <=

    A_21758-05

    Der Konnektor MUSS den technischen Use Case TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren" umsetzen.

    Tabelle 366: TAB_KON_932 – TUC_KON_411 „Konnektor mit neuem NK-Zertifikat registrieren“

    Element
    Beschreibung
    Name
    TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren"
    Beschreibung Dieser TUC führt eine Neuregistrierung mit einem neuen (ECC) NK-Zertifikat durch.
    Auslöser
    A_22332-01, A_23150
    Vorbedingungen
    Die gSMC-K ist gemäß A_18928 dual-personalisiert.
    Eingangsdaten
    Keine
    Komponenten
    Konnektor, VPN-ZugD
    Ausgangsdaten
    Keine
    Standardablauf

    1. Der Konnektor ermittelt die URI des Registrierungsservers (MGM_ZGDP_REGSERVER) durch eine DNS-Anfrage nach dem SRV und TXT Resource Record „_regserver._tcp.<DNS_DOMAIN_VPN_ZUGD_INT>".
    2. Der Konnektor MUSS eine registerKonnektorRequest-Struktur gemäß ProvisioningService.xsd [gemSpec_VPN_ZugD] erstellen und mit den entsprechenden Parametern befüllen (aktuelles Datum/Uhrzeit, neues C.NK.VPN-Zertifikat, MGM_ ZGDP_CONTRACTID). Der Konnektor MUSS die Request-Nachricht mittels einer verfügbaren SM-B  (ID.HCI.OSIG) im Element registerKonnektorRequest/Signature signieren und das SM-B-Zertifikat im Element X509Data ablegen.  (MGM_ ZGDP_SMCB ist zu bevorzugen, es kann aber auch eine andere SM-B verwendet werden).  
    3. Der Konnektor ruft unter Verwendung der erzeugten Request-Nachricht die in [gemSpec_VPN_ZugD#Tab_ZD_registerKonnektor] definierte Operation I_Registration_Service::registerKonnektor mit der Zieladresse MGM_ZGDP_REGSERVER auf.
      Der Response der Operation wird verarbeitet:
      1. Setze MGM_TI_ACCESS_GRANTED auf     
        - Enabled, wenn /RegistrationStatus = „Registriert“    
        - Disabled, wenn /RegistrationStatus = „Nicht registriert“
      2. Persistiere diese Zustandsinformation zusammen mit dem VPN:ContractStatus
      3. Verteile das folgende Ereignis über TUC_KON_256 {
             topic = ”MGM/TI_ACCESS_GRANTED“;
             eventType = Op;
             severity = Info;
             parameters = „Active=$MGM_TI_ACCESS_GRANTED“;
             doLog = true;
             doDisp = true }
    Varianten/Alternativen
    Manuelle Registrierung:
    (->2) Der Administrator soll die zu verwendende SM-B auswählen können.

    Fehlerfälle
    ( 2) Es konnte keine freigeschaltete SM-B ausgewählt werden:
          Fail=No_Smcb
    (->2,3) Im Fehlerfall
           TUC_KON_256 {
                topic = „SMC_K/REGISTER/ERROR“;
                eventType = Op;
                severity = Error;
                parameters = „$Parameters“;
                doLog = true;
                doDisp = true }
    Die Registrierung soll herstellerspezifisch erneut mehrmals versucht werden.
    Bei allen Fehlerfällen, die zum Abbruch führen:
    TUC_KON_256 {
           topic = „SMC_K/REGISTER/ERROR“;
           eventType = Op;
           severity = Error;
           parameters = „$Parameters“;
           doLog = true;
           doDisp = true }

    Nichtfunktionale Anforderungen Keine
    Zugehörige Diagramme
    Keine


    Tabelle 367: Tab_Kon_933 Fehlercodes TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren"

    Fehlercode

    ErrorType

    Severity

    Fehlertext

    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    herstellerspezifisch
    <=

    A_21781

    Der Hersteller des Konnektors MUSS in seinem Handbuch den Nutzer/Administrator darauf hinweisen, dass das Ereignis mit dem Topic=SMC_K/REGISTER/ERROR dringend durch das Primärsystem abonniert werden sollte. Bei Auftreten des Fehlers mit Fail=No_Smcb muss in der Leistungserbringerumgebung dafür gesorgt werden, dass eine freigeschaltete SMC-B verfügbar ist, die der Konnektor beim nächsten Re-Registrierungsversuch verwenden kann. <=

    4.3.9 Remote Management (Optional)

    Im Betreibermodell der TI wird unter Remote Management ein delegierter Betrieb dezentraler Produkte durch einen durch den Anwender beauftragten Servicepartner verstanden. Der Servicepartner stellt als Vertragsbestandteil bevollmächtigte Personen zur Verfügung, die sich ständig um die Betriebs- und Datensicherheit der dezentralen Produkte im Rahmen eines Remote Managements kümmern.

    Voraussetzung für die Etablierung dieses Bestandteils des Betreibermodells der TI ist, dass ein dezentrales Produkt ein Remote Management technisch unterstützt. Die nachfolgend aufgeführten Anforderungen bilden die Grundlage für die Nutzung von Remote Management am Konnektor.

    Zum Remote Management gehören die Verwaltung von Konfigurationsdaten und die Durchführung weiterer Administratoraktionen wie z. B. die Aktualisierung der Software des Konnektors. Im Rahmen des Remote Managements kann der Konnektor Remote Monitoring unterstützen. Dazu übermittelt der Konnektor Betriebszustandsdaten an das Remote- Management-System.

    TIP1-A_7276-01

    Der Konnektor KANN Remote Management technisch unterstützen.
    Falls der Konnektor das Remote Management technisch unterstützt, MUSS der Konnektor alle Anforderungen, die das Remote Management (z.B. auch Remote-Administrator) betreffen, umsetzen.
    Andernfalls sind die Anforderungen, die das Remote Management (z.B. auch Remote-Administrator) betreffen, für den Konnektor nicht relevant. <=

    TIP1-A_5647

    Der Konnektor DARF über die Remote-Managementschnittstelle KEINE personenbezogenen Daten übertragen oder darstellen.

    <=

    TIP1-A_5648

    Der Hersteller des Konnektors MUSS die zur Nutzung der Remote-Managemenschnittstelle notwendigen Informationen offenlegen. Der Hersteller des Konnektors MUSS die Remote-Managementschnittstelle so spezifizieren und implementieren, dass diese auch für Dritte (z.B. einen durch den Anwender beauftragten Servicepartner) nutzbar ist.

    <=

    TIP1-A_5649

    Der Hersteller des Konnektors SOLL für die Implementierung der Remote-Managementschnittstelle standardbasierte Verfahren und Protokolle einsetzen.

    <=

    TIP1-A_5650

    Der Konnektor MUSS sicherstellen, dass die Initiierung einer Remote-Managementverbindung im Sinne des Verbindungsaufbaus immer vom Konnektor ausgeht.
    <=

    TIP1-A_5651

    Der Konnektor MUSS die Remote-Management-Verbindung durch Nutzung eines kryptographischen Verfahrens gemäß [gemSpec_Krypt] hinsichtlich Vertraulichkeit, Integrität und Authentizität absichern.
    <=

    Das Remote-Management-System authentisiert sich auf Transportebene zertifikatsbasiert gegenüber dem Konnektor.

    TIP1-A_7277

    Der Konnektor MUSS eine zertifikatsbasierte Authentifizierung des Remote-Management-Systems auf Transportebene durchführen. <=

    TIP1-A_7278

    Der Konnektor MUSS sich gegenüber dem Remote-Management-System zertifikatsbasiert oder mittels Username/Password authentisieren. <=

    TIP1-A_7281

    Das Remote-Management-System MUSS eine Authentifizierung des Konnektors durchführen. <=

    Die Authentifizierung des Remote-Management-Systems durch den Konnektor auf Transportebene ist verpflichtend gefordert.

    Darüber hinaus können optional Remote-Administratoren in der Benutzerverwaltung des Konnektors konfiguriert werden. Wenn Remote-Administratoren in der Benutzerverwaltung konfiguriert sind, muss der Konnektor diese verpflichtend auf Anwendungsebene authentifizieren.  

    Wenn kein Remote-Administrator konfiguriert ist, vertraut der Konnektor der Benutzerverwaltung des Remote-Management-Systems. Auch wenn die Verwaltung von Remote-Administratoren an das Remote-Management-System delegiert ist, werden alle Zugriffe über das Remote-Management-System auf den Konnektor mit der Rolle Remote-Administrator ausgeführt. Das Remote-Management-System muss die Authentisierung der Remote-Administratoren und die Nachvollziehbarkeit der Zugriffe sicherstellen.

    TIP1-A_7279

    Wenn in der Benutzerverwaltung des Konnektors Administratoren mit der Administrator-Rolle Remote-Administrator konfiguriert sind, MUSS der Konnektor diese gemäß TIP1-A_4808 authentifizieren. <=

    TIP1-A_7280

    Der Konnektor DARF Remote-Administratoren Rechte gemäß TAB_KON_851 und TAB_KON_655 NICHT gewähren. <=

    Tabelle 368: TAB_KON_851 Einschränkung der Rechte des Remote-Administrators (Denylist)

    Fachliche Anbindung der Clientsysteme
    TIP1-A_4517
    Schlüssel und X.509-Zertifikate für die Authentisierung des Clientsystems erzeu­gen und exportieren sowie X.509-Zertifikate importieren
     
    TIP1-A_4518
    Konfiguration der Anbindung Clientsysteme
     
    Kartendienst
    TIP1-A_5110
    Übersicht über alle verfügbaren Karten
    Karten vom Typ eGK und HBA DÜRFEN dem Remote-Administrator NICHT angezeigt werden
    TIP1-A_5111
    PIN-Management der SM-Bs für den Administrator
     
    Zertifikatsdienst
    TIP1-A_4704
    Zertifikatsablauf anzeigen
    Zertifikate von Karten vom Typ eGK und HBA DÜRFEN dem Remote-Administrator NICHT angezeigt werden
    Protokollierungsdienst
    TIP1-A_4716
    Einsichtnahme und Veränderung der Protokolle
    Personenbezogene Daten DARF der Remote-Administrator NICHT einsehen und exportieren. Fachmodulprotokolle müssen daher entweder gesperrt, oder die personenbezogenen Daten aus diesen für den Remote-Administrator gefiltert werden.
    TIP1-A_4814
    Export- Import von Konfigurationsdaten
     
    Neustart und Werksreset
    TIP1-A_4820
    Werksreset des Konnektors
     

    TIP1-A_5652

    Der Konnektor MUSS sicherstellen, dass es ausschließlich einem Administrator mit einer der Rollen {Lokaler Administrator; Super-Administrator} und dem Recht USER_INIT_REMOTESESSION möglich ist, Konfigurationsänderungen gemäß TAB_KON_663 vorzunehmen.

    Tabelle 369: TAB_KON_663 Konfigurationen des Remote Managements

    ReferenzID

    Belegung

    Bedeutung und Administrator-Interaktion

    MGM_REMOTE_
    ALLOWED

    Enabled/
    Disabled

    Der Administrator MUSS einstellen können, ob der
    Konnektor eine Remote-Management-Verbindung
    aufbauen kann, über die Konfigurationen vorgenommen werden können.
    Enabled: Der Konnektor kann eine Remote-
    Management-Verbindung aufbauen und erlaubt Konfiguration über das Remote-Management System.
    Disabled: Der Konnektorerlaubt keine Konfiguration über das Remote Management-System
    Default-Wert: Disabled

    MGM_REMOTE_MONITORING_ALLOWED

    Enabled / Disabled

    Der Konnektor KANN Remote-Monitoring unterstützen.
    In diesem Fall MUSS der Konnektor dem Administrator die Aktivierung und Deaktivierung des Remote-Monitoring ermöglichen.
    Enabled: Der Konnektor baut eine Remote-Managementverbindung auf.
    Der Konnektor übermittelt Betriebszustände gemäß TAB_KON_503 an das Remote-Management-System.
    Disabled: Remote-Monitoring ist deaktiviert. Der Konnektor übermittelt keine Betriebszustände an das Remote-Management-System.
    Default-Wert: Disabled

    Der Konnektor SOLL die Konfiguration der URL des Remote-Management-Systems, der  Zertifikatsinformationen zur Authentisierung des Remote-Management-Systems und der Credentials für die Authentisierung des Konnektors beim Remote-Management-System ermöglichen.


    ​​

    <=

    TIP1-A_5653

    Der Konnektor MUSS im Rahmen des Remote-Managements folgende Aktionen protokollieren:

    <=

    Ein Softwareupdate gemäß TIP1-A_5657 kann auch über das Remote Management initiiert, aktiviert und freigeschaltet werden.

    4.3.10 Software- und Konfigurationsaktualisierung (KSR-Client)

    Die Umsetzung des KSR-Clients bezüglich des Mechanismus zur Durchführung der Aktualisierungen, sowie die Art der Darstellung an der Managementschnittstelle sind herstellerspezifisch.

    Innerhalb der Software- und Konfigurationsaktualisierung (KSR-Client) werden folgende Präfixe für Bezeichner verwendet:

    4.3.10.1 Funktionsmerkmalweite Aspekte

    Der Konnektor muss einen KSR-Client bereitstellen, über den der Administrator sowohl den Konnektor selbst als auch die vom Konnektor verwalteten Kartenterminals (CT-Objects in CTM_CT_LIST mit CT.CORRELATION>=„gepairt“ und CT.VALID_VERSION=True und CT.IS_PHYSICAL = Ja) softwareseitig aktualisieren kann.

    Weiterhin muss über den KSR-Client eine Aktualisierung von ausgewählten Konfigurationsdaten möglich sein.

    TIP1-A_4829

    Die Software-Aktualisierung des Konnektor SOLL sicherstellen, dass alle Software-Bestandteile des Konnektors aktualisiert werden können, damit eine ungehinderte Nachnutzung der Hardware-Basis im Feld mit neuen Funktionalitäten nicht durch nichtaktualisierbare Software-Bestandteile gefährdet wird. Weicht ein Hersteller für sein Konnektormodell von dieser Forderung in Teilen ab, so MUSS er im Rahmen der Zulassung nachweisen, dass dies auf Grund von Sicherheitsaspekten für sein eingereichtes Konnektormodell zwingend erforderlich ist.

    <=

    TIP1-A_5657-02

    Der Konnektor MUSS die Möglichkeit bieten, dass Softwareupdates durch den Nutzer bzw. einen von ihm beauftragten Administrator einzeln freigeschaltet werden.
    <=

    A_18387

    Der Konnektor MUSS die Möglichkeit bieten, die automatische Installation von Softwareupdates pro Gerät (Konnektor und Kartenterminals) ein- und auszuschalten. <=

    A_18389

    Der Hersteller des Konnektors MUSS in seinem Handbuch den Nutzer darauf hinweisen, dass er sich bei der Arbeit mit dem Konnektor vergewissern muss, dass er mit einer zugelassenen Version arbeitet und beschreiben, wie der Nutzer diese Information mittels seines Primärsystems erhalten kann.
    <=

    TIP1-A_6476

    Der Hersteller des Konnektors MUSS jede zugelassene Firmware-Version umgehend als Update-Paket über die in [gemSpec_KSR] definierte Schnittstelle P_KSRS_Upload im Konfigurationsdienst (KSR) ablegen.
    Der Hersteller des Konnektors MUSS in den jeweiligen UpdateInformation/Firmware/FirmwareReleaseNotes eine Internet-URL zum Download des FW-Updates bereitstellen.

    <=

    TIP1-A_6026

    Das Managementinterface des Konnektors MUSS einem authentisierten Administrator die Internet-URL zum Download des FW-Updates anzeigen.
    <=

    4.3.10.2 Durch Ereignisse ausgelöste Reaktionen

    TIP1-A_4831

    Wenn aus (TIP1-A_4840 Auslösen der durchzuführenden Updates) heraus für ein Kartenterminal noch ein ausstehendes Updates vorhanden ist, dessen Ausführungszeitpunkt nicht gesetzt oder überschritten ist, und für dieses Kartenterminal das Ereignis „CT/CONNECTED eintritt, so MUSS TUC_KON_281 „Kartenterminalaktualisierung anstoßen für dieses KT gerufen werden.

    <=

    4.3.10.3 Interne TUCs, nicht durch Fachmodule nutzbar
    4.3.10.3.1 TUC_KON_280 „Konnektoraktualisierung durchführen“

    TIP1-A_4832-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_280 „Konnektoraktualisierung durchführen“ umsetzen.

    Tabelle 370: TAB_KON_664 – TUC_KON_280 „Konnektoraktualisierung durchführen“

    Element
    Beschreibung
    Name
    TUC_KON_280 „Konnektoraktualisierung durchführen“
    Beschreibung
    Dieser TUC aktualisiert den Konnektor mit einem Update, dessen Update-Dateien entweder direkt übergeben oder per UpdateInformation (vom KSRS bezogen) referenziert werden
    Auslöser
    • Der Administrator hat UpdateInformation zur Anwendung ausgewählt und bestätigt bzw. ein lokales Updatepaket bezogen und zur Anwendung übergeben.
    • automatisches Softwareupdate [A_18387] 
    Vorbedingungen

    Eingangsdaten
    • UpdateInformation (gemäß [gemSpec_KSR#5.2])
    oder
    • Updatepaket (herstellerspezifisch, von lokaler Datenquelle, mit enthaltenen FirmwareFiles)
    Komponenten
    Konnektor, Konfigurationsdienst
    Ausgangsdaten
    Keine
    Nachbedingungen
    Der Konnektor arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version.
    Standardablauf
    Der Konnektor MUSS die zur Anwendung übergebene UpdateInformation wie folgt anwenden:
    1. Integrität und Authentizität der UpdateInformation prüfen (Mechanismus ist herstellerspezifisch)
    2. Download aller in UpdateInformation.FirmwareFiles gelisteten Dateien. Dabei wird die Komprimierung des File Transfers vom Konfigurationsdienst über http „Content Coding“ [RFC2616] „gzip“ genutzt.
    3. Integrität und Authentizität jeder der via UpdateInformation/FirmwareFiles heruntergeladenen Dateien prüfen (Mechanismus ist herstellerspezifisch)
    4. Prüfen auf Zulässigkeit des Updates basierend auf der Firmware-Gruppe (siehe [gemSpec_OM#2.5]
    5. Anwenden der zur Verfügung stehenden FirmwareFiles
      1. TUC_KON_256{
            topic = „KSR/UPDATE/START“;
            eventType = Sec;
            severity = Info;
            parameters = („Target=Konnektor,
                                  Name=$MGM_KONN_HOSTNAME“)}
        (betroffene Fachmodule und Basisdienste reagieren und stoppen sich)
      2. Herstellerspezifischer Mechanismus zur Aktualisierung der internen Konnektorsoftware durch die FirmwareFiles inklusive anschließender Prüfung auf Erfolg.
      3. Bestehende Konfigurationsdaten des Konnektors MÜSSEN erhalten bleiben und sofern erforderlich und möglich automatisch auf die Definitionen der neuen Firmware angepasst werden.
      4. Ist ein händischer Anpassungs- oder Ergänzungsbedarf der Konfigurationsdaten erforderlich, so MUSS der Administrator hierüber geeignet informiert werden
      5. TUC_KON_256 {
            topic = „KSR/UPDATE/SUCCESS”;
            eventType = Sec;
            severity = Info;
            parameters = („Target=Konnektor,
                        Name= $MGM_KONN_HOSTNAME,
                        NewFirmwareversion =
                                UpdateInformation.FirmwareVersion,
                        ConfigurationChanged=<Ja/Nein>,
                        ManualInputNeeded=<Ja/Nein>„) }
    Der TUC endet in jedem Fall mit:
    TUC_KON_256 {
        topic = „KSR/UPDATE/END“;
        eventType = Sec;
        severity = Info;
        parameters = („Target=Konnektor,
                               Name=$MGM_KONN_HOSTNAME“) }
    (betroffene Fachmodule und Basisdienste reagieren und starten sich)
    Varianten/Alternativen
    Sofern direkt ein Updatepaket (mit enthaltenen FirmwareFiles) übergeben wurde beginnt der Ablauf ab Nummer 4 mit der Integritätsprüfung des Updatepakets
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu:
    a) Aufruf von TUC_KON_256 {
              topic = „KSR/ERROR“;
              eventType = $ErrorType;
              severity = $Severity;
              parameters = („Target=Konnektor,
                     Name= $MGM_KONN_HOSTNAME,
                     Error=$Fehlercode,
                     Bedeutung=$Fehlertext“) }
    b) Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes

    (1) Integritätsprüfung UpdateInformation fehlgeschlagen, Fehlercode: 4181
    (2) Fehler bei der Downloaddurchführung, Fehlercode: 4182
    (3) Integritätsprüfung eines FirmwareFiles fehlgeschlagen, Fehlercode: 4183
    ( 4) Firmwaregruppenprüfung fehlgeschlagen, Fehlercode: 4185
    (5b) Interne Aktualisierung fehlgeschlagen, dann:
              1. Rollback auf vorherige Version
              2. Abbruch mit Fehlercode: 4184
    Nichtfunktionale Anforderungen
    Der laufende Updatevorgang MUSS in der Managementschnittstelle ausgewiesen und der Fortschritt mindestens für die Schritte 1-5b dargestellt werden.
    Zugehörige Diagramme
    Abbildung PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen

    Tabelle 371: TAB_KON_665 Fehlercodes TUC_KON_280 „Konnektoraktualisierung durchführen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4181
    Security
    Error
    Integritätsprüfung UpdateInformation fehlgeschlagen.
    4182
    Security
    Error
    Download nicht aller UpdateFiles möglich.
    4183
    Security
    Error
    Integritätsprüfung UpdateFiles fehlgeschlagen.
    4184
    Security
    Error
    Anwendung der UpdateFiles fehlgeschlagen (<Details>).
    4185
    Security
    Error
    Firmware-Version liegt außerhalb der gültigen Firmware-Gruppe



    Abbildung 22: PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen  

    <=

    4.3.10.3.2 TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

    Im Vergleich zur Durchführung des Konnektor-Update (TUC_KON_280), werden die Updates der Kartenterminals nur durch den Konnektor initiiert. Der Konnektor liefert dem Kartenterminal das Updatefile, der eigentliche Updatevorgang (inklusive der Prüfung des Updatepakets auf Integrität und Authentizität) erfolgt ausschließlich und eigenverantwortlich auf Seiten des Kartenterminals.

    TIP1-A_4833-02

    Der Konnektor MUSS den technischen Use Case TUC_KON_281 „Kartenterminalaktualisierung anstoßen“ umsetzen.

    Tabelle 372: TAB_KON_666 – TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

    Element
    Beschreibung
    Name
    TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
    Beschreibung
    Dieser TUC fordert ein Kartenterminal auf einen Update durchzuführen, dessen Update-Dateien entweder direkt übergeben oder per UpdateInformation (vom KSRS bezogen) referenziert werden
    Auslöser
    • Der Administrator hat UpdateInformation für ein Kartenterminal zur Anwendung ausgewählt und bestätigt bzw. ein lokales Updatepaket für ein Kartenterminal bezogen und zur Anwendung übergeben.
    • automatisches Softwareupdate [A_18387] 
    Vorbedingungen
    •     CT(ctId).IS_PHYSICAL=Ja
    •     CT(ctId).CORRELATION>=”gepairt”
    Eingangsdaten
    •       ctId (ID des Ziel-KTs)
    •       UpdateInformation (gemäß [gemSpec_KSR]) oder
    •       Updatepaket (herstellerspezifisch, von lokaler Datenquelle, mit enthaltenen FirmwareFiles)
    Komponenten
    Konnektor, Kartenterminal
    Ausgangsdaten
    Keine
    Nachbedingungen
    Das Kartenterminal arbeitet basierend auf der übergebenen, im Updatepaket enthaltenen neuen Version.
    Standardablauf
    Der Konnektor MUSS die zur Anwendung übergebene UpdateInformation wie folgt anwenden:
    1. Download der in UpdateInformation/FirmwareFiles gelisteten Datei (für KT-Updates darf nur genau ein FirmwareFile angegeben werden)
    2. TUC_KON_256{
      topic = „KSR/UPDATE/START”;
          eventType = Sec;
          severity = Info;
          parameters = („Target=KT, CtID=$ctId“) }

    3. Durchführen des KT-Updates durch:
    a)         Wechsel in eine Admin-Session durch TUC_KON_050
         „Beginne Kartenterminalsitzung“{role=„Admin“; ctId}

    b)         Senden der SICCT Kommandos: SICCT CT Download INIT,
         SICCT CT Download DATA (Übermittlung des UpdateFiles) und
         SICCT CT Download FINISH an ctId

    c)         TUC_KON_256{
              topic = „KSR/UPDATE/SUCCESS”;
              eventType = Sec;
              severity = Info;
              parameters = („Target=KT,
                     Name= $CT.HOSTNAME, CtID =$ctId,
                     NewFirmwareversion =
                              <UpdateInformation.FirmwareVersion>„}


    Der TUC endet in jedem Fall mit:
    • TUC_KON_256 {
              topic = „KSR/UPDATE/END”;
              eventType = Sec;
              severity = Info;
              parameters = („Target=KT, CtID =$ctId“) }

    Varianten/Alternativen
    Sofern direkt ein Updatepaket (mit enthaltenem FirmwareFile) übergeben wurde beginnt der Ablauf ab Nummer 2 mit Signalisierung des Beginns des KT-Updates
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu:
    a)           Aufruf von TUC_KON_256 {
               topic = „KSR/ERROR”;
               eventType = $ErrorType;
               severity = $Severity;
               parameters = („Target=KT, Name=$CT.HOSTNAME,
                           CtID =$ctId, Error=$Fehlercode,
                           Bedeutung=$Fehlertext“) }

    b)           Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
    (1) Download fehlgeschlagen, Fehlercode: 4186
    (3b) SICCT-Download fehlgeschlagen, Fehlercode: 4187
    Nichtfunktionale Anforderungen
    Die Durchführung eines KT-Updates DARF die weitere Operation des Konnektors NICHT behindern (weder auf Schnittstellenebene noch in der Managementschnittstelle).
    Der laufende Updatevorgang eines KT MUSS in der Managementschnittstelle ausgewiesen und der Fortschritt dargestellt werden.
    Der Konnektor MUSS mindestens 5 Kartenterminal-Updates parallel durchführen können.
    Zugehörige Diagramme
    keine

    Tabelle 373: TAB_KON_667 Fehlercodes TUC_KON_281 „Kartenterminalaktualisierung anstoßen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4186
    Security
    Error
    Download nicht aller UpdateFiles möglich.
    4187
    Security
    Error
    KT-Update fehlgeschlagen (<Fehlerinfo gemäß SICCT>)
    <=

    4.3.10.3.3 TUC_KON_282 „UpdateInformationen beziehen“

    TIP1-A_4834

    Der Konnektor MUSS den technischen Use Case TUC_KON_282 „UpdateInformationen beziehen“ umsetzen.

    Tabelle 374: TAB_KON_668 – TUC_KON_282 „UpdateInformationen beziehen“

    Element
    Beschreibung
    Name
    TUC_KON_282 „UpdateInformationen beziehen“
    Beschreibung
    Dieser TUC ermittelt vom zentralen Konfigurationsdienst sowohl für den Konnektor als auch für alle durch ihn verwalteten Kartenterminals die verfügbaren UpdateInformationen
    Auslöser
    • Manuell durch den Administrator
    • Automatisch
    Vorbedingungen
    Keine
    Eingangsdaten
    Keine
    Komponenten
    Konnektor, Konfigurationsdienst
    Ausgangsdaten
    Keine
    Nachbedingungen
    Der Konnektor verfügt über alle aktuellen UpdateInformationen
    Standardablauf
    Der Konnektor MUSS folgende Schritte durchlaufen:
    1. Der Konnektor MUSS die TLS-Verbindungen zum Konfigurationsdienst anhand des in MGM_KSR_FIRMWARE_URL angegebenen Wertes aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels
      TUC_KON_037 „Zertifikat prüfen“ {
          certificate = C.ZD.TSL-S;
          qualifiedCheck = not_required;
          offlineAllowNoCheck = true;
          policyList = oid_zd_tls_s;  
          intendedKeyUsage= intendedKeyUsage(C.ZD.TSL-S);
          intendedExtendedKeyUsage = id-kp-serverAuth;
          validationMode = OCSP}
      auf Gültigkeit prüfen.
      Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.
    1. Der Konnektor MUSS sowohl für sich wie auch für jedes Kartenterminal (CT) aus CTM_CT_LIST mit CT.IS_PHYSICAL=Ja und CT.CORRELATION>=„gepairt“ folgende Schritte durchlaufen:
      1.         Belegen von listUpdatesRequest mit den korrekten Werten für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion
      2.         Aufruf von I_KSRS_Download::list_Updates

        Liefert der Aufruf mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/FWVersion > aktuelle Version der Konnektorsoftware, deren UpdateInformation/Firmware/FWPriority = „Kritisch“, dann geht der Konnektor über in den Betriebszustand EC_Connector_Software_Out_Of_Date.

        Liefert der Aufruf mindestens eine UpdateInformation mit einer UpdateInformation/Firmware/FWVersion > aktuelle Version der Kartenterminalsoftware, deren UpdateInformation/Firmware/FWPriority = „Kritisch“, dann geht der Konnektor über in den Betriebszustand EC_CardTerminal_Software_Out_Of_Date.
    2. Beenden der TLS-Verbindung
    Varianten/Alternativen
    Keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu:
    a)          Aufruf von TUC_KON_256 {
               topic = „KSR/ERROR“;
               eventType = $ErrorType;
               severity = $Severity;
               parameters = („Error=$Fehlercode; Bedeutung=$Fehlertext“)}


    b)          Abbruch der Verarbeitung mit den ausgewiesenen Fehlercodes
    (1) Konfigurationsdienst nicht erreichbar, Fehlercode: 4188
    (1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189
    (2b) Fehler beim Beziehen der Updatelisten, Fehlercode: 4190
    Nichtfunktionale Anforderungen
    Der Konnektor muss die Vorgaben aus [gemSpec_Krypt#3.3.2] für TLS-Verbindungen und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen.
    Zugehörige Diagramme
    keine

    Tabelle 375: TAB_KON_669 Fehlercodes TUC_KON_282 „UpdateInformationen beziehen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases, sowie der Fehlercodes von „I_KSRS_Download::listUpdates Response“ können folgende weitere Fehlercodes auftreten:
    4188
    Technical
    Error
    Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren.
    4189
    Security
    Fatal
    Konfigurationsdienst liefert falsches Zertifikat
    4190
    Technical
    Error
    Fehler beim Beziehen der Updatelisten

    <=

    4.3.10.3.4 TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“

    TIP1-A_5153

    Der Konnektor MUSS den technischen Use Case TUC_Kon_283 „Infrastruktur Konfiguration aktualisieren“ umsetzen.

    Tabelle 376: TAB_KON_799 – TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“

    Element
    Beschreibung
    Name
    TUC_KON_283 Infrastruktur Konfiguration aktualisieren
    Beschreibung
    Dieser TUC liest die Infrastrukturdaten vom KSR ein.
    Auslöser
    Automatisch einmal täglich; BOOTUP, Administrator
    Vorbedingungen Der TUC_KON_304 „Netzwerk-Routen einrichten“ MUSS fehlerfrei durchgelaufen sein.
    Der TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“ MUSS fehlerfrei durchgelaufen sein.
    Eingangsdaten
    Keine
    Komponenten
    Konnektor, Konfigurationsdienst
    Ausgangsdaten
    Keine
    Standardablauf

    Der Konnektor MUSS folgende Schritte durchlaufen:
    1. „Einlesen des Konfigurations-XML“:
      1. Der Konnektor MUSS eine TLS-Verbindung zum Konfigurationsdienst anhand des in MGM_KSR_KONFIG_URL angegebenen Parameters aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels TUC_KON_037 „Zertifikat prüfen“ {
               certificate = C.ZD.TSL-S;
               qualifiedCheck = not_required;  
               offlineAllowNoCheck = true;
               policyList = oid_zd_tls_s;
               intendedKeyUsage =
                      intendedKeyUsage(C.ZD.TSL-S);
               intendedExtendedKeyUsage = id-kp-serverAuth;  
               validationMode = OCSP}
        auf Gültigkeit prüfen.
        Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.
      2. Herunterladen der Konfigurationsdaten mittels I_KSRS_Download::get_Ext_Net_Config (MGM_KSR_KONFIG_URL, „Bestandsnetze.xml“)
    2. Beenden der TLS-Verbindung
      „Prüfen der Versionskennung auf Änderungen“:
      Wenn das Element /Infrastructure/Version der heruntergeladenen Datei keine höhere Versionsnummer als die aktuell im Konnektor hinterlegte Version trägt, muss der TUC ohne Fehler beendet und ein Protokolleintrag geschrieben werden:
      TUC_KON_271 „Schreibe Protokolleintrag“ {
          topic = „KSR/UPDATE_KONFIG“;
          eventType = Op;
          severity = Info;
          parameters = („AlteVersion=$aktuelleVersion,
                                  NeueVersion=/Infrastructure/Version“)}
    3. Aktualisieren der Gesamtnetzliste
      Alle in der Datei enthaltenen Netzsegmente sind nach
      ANLW_BESTANDSNETZE zu übernehmen. In Abhängigkeit von ANLW_IA_BESTANDSNETZE sind neue angeschlossene Netze des Gesundheitswesens mit WANDA Basic nach ANLW_AKTIVE_BESTANDSNETZE zu übernehmen. Identifiziert wird ein Bestandsnetz hierbei an dessen ID in der Bestandsnetze.xml (<ID>). War der Aktivierungsstatus eines dieser Netze bereits durch den Administrator manuell konfiguriert, so muss dieser Status erhalten bleiben.

    4. „Aktualisieren von Konfigurationsinformationen“
      Haben sich Konfigurationsdaten zu einem in ANLW_AKTIVE_BESTANDSNETZE gelisteten Netz verändert, so
      1. sind die Änderungen entsprechend zu übernehmen und zu aktivieren (Anpassung ANLW_AKTIVE_BESTANDSNETZE, DHCP_AKTIVE_BESTANDSNETZE_ROUTES, DNS_SERVERS_BESTANDSNETZE).
      2. alle Statusänderungen an ANLW_AKTIVE_BESTANDSNETZE sind zu protokollieren. Der Protokolleintrag je Änderung enthält den Status, <ID>, <Name> und <NetworkAddress/NetworkPrefix> als topic=KSR/UPDATE_KONFIG, protocolType=OP und protocolSeverity=INFO.
      3. ist anschließend TUC_KON_304 „Netzwerk-Routen einrichten“ aufzurufen

    5. „Entfernen von nicht mehr gültigen angeschlossenen Netzen des Gesundheitswesens mit WANDA Basic“
      Ist ein Netz in der neuen Datei gegenüber der alten Datei nicht mehr vorhanden, so:
      1. a) sind alle diesbezüglichen Daten zu entfernen und die Änderungen direkt aktiv zu schalten (Anpassung ANLW_AKTIVE_BESTANDSNETZE, DHCP_AKTIVE_BESTANDSNETZE_ROUTES, DNS_SERVERS_BESTANDSNETZE).
      2. b) ist anschließend TUC_KON_304 „Netzwerk-Routen einrichten“ aufzurufen.
    6. Protokollierung der heruntergeladenen Version von Bestandsnetze.xml durch Aufruf von
      TUC_KON_271 „Schreibe Protokolleintrag“ {
          topic = „KSR/UPDATE_KONFIG“;
          eventType = Op;
          severity = Info;
          parameters = („AlteVersion=$aktuelleVersion,
                                  NeueVersion=/Infrastructure/Version“)}
    Varianten/Alternativen
    Keine
    Fehlerfälle
    ( 1-5) Es ist ein unerwarteter Fehler aufgetreten; Fehlercode: 4198
    Nichtfunktionale Anforderungen Keine
    Zugehörige Diagramme
    Keine

    Tabelle 377: Tab_Kon_726 Fehlercodes TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4198

    Technical

    Error

    Beim Übernehmen der angeschlossenen Netze des Gesundheitswesens mit WANDA Basic ist ein Fehler aufgetreten.
    <=

    4.3.10.4 Interne TUCs, auch durch Fachmodule nutzbar
    4.3.10.4.1 TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

    TIP1-A_6018

    Der Konnektor MUSS den technischen Use Case TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“ umsetzen.

    Tabelle 378: TAB_KON_833 – TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

    Element
    Beschreibung
    Name
    TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
    Beschreibung
    Dieser TUC ermittelt vom zentralen Konfigurationsdienst für ein Fachmodul die verfügbaren UpdateInformationen eines angegebenen SW-Pakets.
    Auslöser
    •         Aufruf durch Fachmodul
    Vorbedingungen
    • Verbindung zum VPN-Konzentrator der TI wurde erfolgreich aufgebaut
    Eingangsdaten
    •         productVendorID [String] -
      (Identifiziert den Hersteller des Produkts, für welches auf Updates geprüft werden soll.)
    •         productCode [String]
      (Identifiziert das Produkt zusammen mit ProductVendorID, für welches auf Updates geprüft werden soll.)
    •         hwVersion [String]
      (Identifiziert die Hardware zusammen mit ProductCode und ProductVendorID, für welches auf Updates geprüft werden soll. [gemSpec_OM] beschreibt dieses Element ausführlich.)
    •         fwVersion [String]
      aktuell im Produkt verwendete Firmwareversion
    Hinweis: Definition von productVendorID, productCode, hwVersion, fwVersion (entspricht FWVersion) siehe [gemSpec_KSR#TIP1-A_3331]
    Komponenten
    Konnektor, Konfigurationsdienst
    Ausgangsdaten
    • listOfUpdates [listUpdatesResponse]
      Liste von Update Informationen der verfügbaren Pakete für das angegebene Produkt;
      Datentyp listUpdatesResponse definiert in Konfigurationsdienst.xsd siehe [gemSpec_KSR]
    Nachbedingungen
    keine
    Standardablauf
    Der Konnektor MUSS folgende Schritte durchlaufen:
    1. Der Konnektor MUSS die TLS-Verbindung zum Konfigurationsdienst anhand des in MGM_KSR_FIRMWARE_URL angegebenen Wertes aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels
      TUC_KON_037 „Zertifikat prüfen“ {
          certificate = C.ZD.TSL-S;
          qualifiedCheck = not_required;
          offlineAllowNoCheck = true;
          policyList = oid_zd_tls_s;  
          intendedKeyUsage = intendedKeyUsage(C.ZD.TSL-S);
          intendedExtendedKeyUsage = id-kp-serverAuth;
          validationMode = OCSP}
      auf Gültigkeit prüfen.
      Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.
    1. Belegen von listUpdatesRequest mit den korrekten Werten für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion = fwVersion
    2. Aufruf von I_KSRS_Download::list_Updates gemäß [gemSpec_KSR#TIP1-A_3331]
    3. Beenden der TLS-Verbindung
    Varianten/Alternativen
    Keine
    Fehlerfälle
    Fehler in den folgenden Schritten des Ablaufs führen zu:
    (1)    Konfigurationsdienst nicht erreichbar, Fehlercode: 4188
    (1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189
    (3) Fehler beim Beziehen der Updatelisten, Fehlercode: 4190
    Nichtfunktionale Anforderungen
    Der Konnektor muss die Vorgaben aus [gemSpec_Krypt#3.3.2] für TLS-Verbindungen und hinsichtlich ECC-Migration die Vorgaben aus [gemSpec_Krypt#5] befolgen.
    Zugehörige Diagramme
    keine

    Tabelle 379: TAB_KON_834 Fehlercodes TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases, sowie der Fehlercodes von „I_KSRS_Download::listUpdates Response“ können folgende weitere Fehlercodes auftreten:
    4188
    Technical
    Error
    Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren.
    4189
    Security
    Fatal
    Konfigurationsdienst liefert falsches Zertifikat
    4190
    Technical
    Error
    Fehler beim Beziehen der Updatelisten

    <=

    4.3.10.4.2 TUC_KON_286 „Paket für Fachmodul laden“

    TIP1-A_6019

    Der Konnektor MUSS den technischen Use Case TUC_KON_286 „Paket für Fachmodul laden“ umsetzen.

    Tabelle 380: TAB_KON_835 – TUC_KON_286 „Paket für Fachmodul laden“

    Element
    Beschreibung
    Name
    TUC_KON_286 „Paket für Fachmodul laden“
    Beschreibung
    Dieser TUC lädt ein bestimmtes SW-Paket für ein Fachmodul vom zentralen Konfigurationsdienst.
    Auslöser
    Aufruf durch Fachmodul
    Vorbedingungen
    • Verbindung zum VPN-Konzentrator der TI wurde erfolgreich aufgebaut
    Eingangsdaten
    •       filename
      (Filename des SW-Pakets, welches vom KSR geladen werden soll)

    Komponenten
    Konnektor, Konfigurationsdienst
    Ausgangsdaten
    • swPackage
      (das durch filename am KSR identifizierte SW-Paket wurde heruntergeladen)

    Nachbedingungen
    keine
    Standardablauf
    1. Der Konnektor MUSS die TLS-Verbindung zum Konfigurationsdienst anhand des in MGM_KSR_FIRMWARE_URL angegebenen Wertes aufbauen. Dabei MUSS er das durch den Server präsentierte Zertifikat mittels
      TUC_KON_037 „Zertifikat prüfen“ {
          certificate = C.ZD.TSL-S;
          qualifiedCheck = not_required;
          offlineAllowNoCheck = true;
          policyList = oid_zd_tls_s;  
          intendedKeyUsage = intendedKeyUsage(C.ZD.TSL-S);
          intendedExtendedKeyUsage = id-kp-serverAuth;
          validationMode = OCSP}
      auf Gültigkeit prüfen.

    Das Server-Zertifikat C.ZD.TLS-S MUSS für den Konfigurationsdienst ausgestellt sein.
    1. Herunterladen der Softwarepakets swPackage mittels I_KSRS_Download::get_File (MGM_KSR_FIRMWARE_URL /$filename)
    2. Beenden der TLS-Verbindung
    3. swPackage an Aufrufer zurückgeben
    Varianten/Alternativen
    keine
    Fehlerfälle
    ( 1) Verbindung zum KSR konnte nicht aufgebaut werden; Fehlercode: 4188
    ( 1) Serverzertifikat ist nicht C.ZD.TLS_S, Fehlercode: 4189
    ( 2) Wenn Größe des Pakets größer als 25MB, Fehlercode: 4242
    ( 2) Sonstige Fehler beim Download: Das Paket konnte nicht geladen werden, Fehlercode: 4238
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 381: TAB_KON_836 Fehlercodes TUC_KON_286 „Paket für Fachmodul laden“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können folgende weitere Fehlercodes auftreten:
    4188
    Technical
    Error
    Konfigurationsdienst nicht erreichbar, konfigurierte Adresse kontrollieren.
    4189
    Security
    Fatal
    Konfigurationsdienst liefert falsches Zertifikat
    4238
    Technical
    Error
    Der Download des Pakets vom KSR ist fehlgeschlagen.
    4242
    Technical
    Error
    Der Download des Pakets vom KSR ist fehlgeschlagen. Das Paket ist größer als 25MB.

    <=

    4.3.10.5 Operationen an der Außenschnittstelle

    Keine.

    4.3.10.6 Betriebsaspekte

    A_21899

    Der Konnektor DARF NICHT nach einer Aktualisierung der Datei Bestandsnetze.xml einen Restart durchführen.
    <=

    A_21900

    Der Konnektor MUSS die Anzahl der Reboots minimieren. <=

    4.3.10.6.1 TUC_KON_284 KSR-Client initialisieren

    TIP1-A_5938

    Der Konnektor MUSS in der Bootup-Phase TUC_KON_284 „KSR-Client initialisieren“ durchlaufen.

    Tabelle 382: TAB_KON_864 – TUC_KON_284 „KSR-Client initialisieren“

    Element
    Beschreibung
    Name
    TUC_KON_284 ”KSR-Client initialisieren”
    Beschreibung
    Der Konnektor muss während des Bootups die Downloadpunkte für Konfigurationsdaten und Firmware ermitteln.
    Eingangsanforderung
    Keine
    Auslöser und Vorbedingungen
    Bootup
    Verbindung zum VPN-Konzentrator TI muss aufgebaut sein
    Eingangsdaten
    Keine
    Komponenten
    Konnektor
    Ausgangsdaten
    • MGM_KSR_KONFIG_URL
    • MGM_KSR_FIRMWARE_URL
    Standardablauf
     -             Falls MGM_LU_ONLINE=Enabled:
                -              Durch DNS-Anfragen an den DNS-Forwarder zur
                     Auflösung der SRV-RR und TXT-RR mit den Bezeichnern
                    „_ksrkonfig._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ und
                    „_ksrfirmware._tcp.ksr.<TOP_LEVEL_DOMAIN_TI>„ erhält
                     der Konnektor URLs der Downloadpunkte des KSR für
                    Konfigurationsdaten (MGM_KSR_KONFIG_URL) und für
                    Firmware (MGM_KSR_FIRMWARE_URL).


    Varianten/Alternativen
    Keine
    Fehlerfälle
    Keine
    Nichtfunktionale Anforderungen
    Keine
    Zugehörige Diagramme
    Keine

    Tabelle 383: TAB_KON_822 Fehlercodes TUC_KON_284 „KSR-Client initialisieren“

    Fehlercode
    ErrorType
    Severity
    Fehlertext
    Neben den Fehlercodes der aufgerufenen technischen Use Cases können keine weiteren Fehlercodes auftreten.

    <=

    TIP1-A_4835-02

    Der Administrator MUSS die in TAB_KON_670 aufgelisteten Parameter über die Managementschnittstelle konfigurieren und die in TAB_KON_820 aufgelisteten Parameter ausschließlich einsehen können.

    Tabelle 384: TAB_KON_670 Konfigurationsparameter der Software-Aktualisierung

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    MGM_KSR_
    AUTODOWNLOAD
    Enabled/
    Disabled
    Der Administrator MUSS den automatischen Download verfügbarer Update-Pakete über den Konfigurationsparameter MGM_KSR_AUTODOWNLOAD an- und abschalten können.
    Default-Wert: Enabled
    MGM_KSR_SHOW_
    TRIAL_UPDATES
    Enabled /
    Disabled
    Der Administrator MUSS einschalten können, dass zusätzlich zur Anzeige von Update-Paketen für den Online-Produktivbetrieb auch die Anzeige von Erprobungs-Update-Paketen erfolgt.
    Wenn MGM_KSR_SHOW_TRIAL_UPDATES von Disabled auf Enabled gesetzt wird, muss ein Warnhinweis angezeigt werden, dass die Installation von Erprobungs-Update-Paketen nur für Teilnehmer der Erprobungen vorgesehen ist.
    Default-Wert: Disabled
    MGM_KSR_AUTO_UPDATE Enabled / Disabled Der Administrator MUSS pro Gerät (Konnektor und Kartenterminals) das automatische Softwareupdate ein- und ausschalten können.
    Default-Wert: Enabled
    Falls MGM_KSR_AUTO_UPDATE=Enabled wird MGM_KSR_
    AUTODOWNLOAD=
    Enabled gesetzt.
    MGM_KSR_AUTO_
    UPDATE_TIME
    Wochentag / Uhrzeit
    Oder
    täglich / Uhrzeit
    Der Administrator MUSS den Wochentag und die Uhrzeit einstellen können, wann automatische Softwareupdates durchgeführt werden.
    Als Wochentag MUSS es neben den einzelnen Wochentagen auch einen Wert für eine tägliche Prüfung auf Aktualität und gegebenenfalls Durchführung von Softwareupdates geben.
    Default-Wert: Montag / 1:00 Uhr

    Tabelle 385: TAB_KON_820 Einsehbare Konfigurationsparameter der Software-Aktualisierung

    ReferenzID
    Belegung
    Bedeutung und Administrator-Interaktion
    MGM_KSR_
    KONFIG_URL
    URL
    SOAP-Endpunkt des Konfigurationsdienstes zum Download von Konfigurationsdaten
    MGM_KSR_
    FIRMWARE_URL
    URL
    SOAP-Endpunkt des Konfigurationsdienstes zum Download der Firmware
    <=

    Hinweis: Die Adressen des Konfigurationsdienstes werden im Rahmen des VPN-Verbindungsaufbaus ermittelt (siehe [gemSpec_VPN_ZugD#5.1.1.2 TUC_VPN-ZD_0001])

    TIP1-A_6025

    Der Konnektor MUSS täglich überprüfen, ob unter den auf die aktuelle Konnektor-Firmware anwendbaren Updates  ein Update mit FWPriority = „Kritisch“ ist, dessen Deadline (entspricht UpdateInformation/DeploymentInformation/Deadline) abgelaufen ist, d.h. Deadline <= Systemzeit. In diesem Fall MUSS der Konnektor den Verbindungsaufbau zur TI Plattform verhindern, bestehende Verbindungen in die TI abbauen und den kritischen Betriebszustand EC_FW_Not_Valid_Status_Blocked annehmen.
    <=

    TIP1-A_4836

    Der Konnektor MUSS täglich die folgenden Schritte durchführen:

    1. TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
    2. pro zurück geliefertem Listeneintrag prüfen, ob eine neuere Version enthalten ist, als auf dem zugehörigen Gerät (Konnektor selbst oder Kartenterminal) vorhanden
    3. Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor darüber via    
      TUC_KON_256 „Systemereignis absetzen“ {
              topic = „KSR/UPDATES_AVAILABLE“;     
              eventType = Op;     
              severity = Info;     
              parameters  = (<Param>);    
              doLog=false }    
      informieren. Je gefundenem Update MUSS <Param> mit folgenden Werten belegt sein:    
      <Param> =     „ProductVendorID= $UpdateInformation/ProductVendorID;
                           ProductCode= $UpdateInformation/ProductCode;
                           ProductName=$UpdateInformation/ProductName;
                           FirmwareVersion=$UpdateInformation/FirmwareVersion;
                           Deadline=$UpdateInformation/DeploymentInformation/Deadline;
                           FWPriority=$UpdateInformation/Firmware/FWPriority;
                           F
      irmwareReleaseNotes=
                                            $UpdateInformation/Firmware/FirmwareReleaseNotes“
    4. Die listUpdateResponse mit neueren Firmwareversionen MÜSSEN für eine spätere Einsichtnahme durch den Administrator bereitgehalten werden (via (TIP1-A_4837) „Übersichtsseite des KSR-Client). Ein neuerlicher Abruf dieser Informationen DARF NICHT erforderlich sein.
    5. Sofern ein Update-Paket für den Konnektor vorliegt, MUSS der Konnektor die mit diesem Paket gelieferten Parameter Priority (entspricht UpdateInformation/Firmware/FWPriority) und Deadline (entspricht UpdateInformation/DeploymentInformation/Deadline) auswerten und bei KSR:Priority=Kritisch persistent ablegen.
    6. Sofern MGM_KSR_AUTODOWNLOAD = Enabled, MUSS der Konnektor bei Update-Paketen, die den Konnektor selbst betreffen, das Update-Paket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen.
    7. Ist der Download von Update-Paketen für den Konnektor abgeschlossen, MUSS der Konnektor darüber via
    TUC_KON_256 „Systemereignis absetzen“ {
            topic = „KSR/UPDATE/KONNEKTOR_DOWNLOAD_END“;
            eventType = Op;     
            severity = Info;     
            parameters  = (<Param>)}    
    informieren. Je heruntergeladenem FW-Paket MUSS <Param> mit folgenden Werten belegt sein:    
    <Param> =     „ProductVendorID= $UpdateInformation/ProductVendorID;
                         ProductCode= $UpdateInformation/ProductCode;
                         ProductName=$UpdateInformation/ProductName;
                         FirmwareVersion=$UpdateInformation/Firmware/FWVersion;
                         Deadline=$UpdateInformation/DeploymentInformation/Deadline;
                         FWPriority=$UpdateInformation/Firmware/ FWPriority;
                         FirmwareReleaseNotes
                                         =$UpdateInformation/Firmware/FirmwareReleaseNotes“
    1. Sofern MGM_KSR_AUTODOWNLOAD = Enabled, SOLL der Konnektor bei Update-Paketen, die Kartenterminals betreffen, pro KT-Modell das Update-Paket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen.

    Der Konnektor MUSS immer nur die neusten Update-Pakete für eine Nutzung vorhalten. Eventuell vorhandene ältere, nicht genutzte Update-Pakete KÖNNEN überschrieben werden. <=

    TIP1-A_4836-02

    Der Konnektor MUSS täglich die folgenden Schritte durchführen:

    1. TUC_KON_282 „UpdateInformationen beziehen“ aufrufen.
    2. pro zurück geliefertem Listeneintrag prüfen, ob eine neuere Version enthalten ist, als auf dem zugehörigen Gerät (Konnektor selbst oder Kartenterminal) vorhanden
    3. Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor darüber via    
      TUC_KON_256 „Systemereignis absetzen“ {
              topic = „KSR/UPDATES_AVAILABLE“;     
              eventType = Op;     
              severity = Info;     
              parameters  = (<Param>);    
              doLog=false }    
      informieren. Je gefundenem Update MUSS <Param> mit folgenden Werten belegt sein:    
      <Param> =     „ProductVendorID= $UpdateInformation/ProductVendorID;
                           ProductCode= $UpdateInformation/ProductCode;
                           ProductName=$UpdateInformation/ProductName;
                           FirmwareVersion=$UpdateInformation/FirmwareVersion;
                           Deadline=$UpdateInformation/DeploymentInformation/Deadline;
                           FWPriority=$UpdateInformation/Firmware/FWPriority;
                           FirmwareReleaseNotes=
                                            $UpdateInformation/Firmware/FirmwareReleaseNotes“
    4. Ist für wenigstens ein Gerät eine neuere Version vorhanden, MUSS der Konnektor in den Betriebszustand EC_FW_Update_Available übergehen.
    5. Die listUpdateResponse mit neueren Firmwareversionen MÜSSEN für eine spätere Einsichtnahme durch den Administrator bereitgehalten werden (via (TIP1-A_4837) „Übersichtsseite des KSR-Client). Ein neuerlicher Abruf dieser Informationen DARF NICHT erforderlich sein.
    6. Sofern ein Update-Paket für den Konnektor selbst vorliegt, MUSS der Konnektor die mit diesem Paket gelieferten Parameter Priority (entspricht UpdateInformation/Firmware/FWPriority) und Deadline (entspricht UpdateInformation/DeploymentInformation/Deadline) auswerten und bei KSR:Priority=Kritisch persistent ablegen.
    7. Sofern MGM_KSR_AUTODOWNLOAD = Enabled, MUSS der Konnektor bei Update-Paketen, die den Konnektor selbst betreffen, das Updatepaket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen, falls das Update-Paket nicht bereits von einem vorherigen Download auf dem Konnektor vorhanden ist.
    8. Sofern I_KSRS_Download::get_Updates den http Status Code 503 Server Unavailable zurückgibt, MUSS der Konnektor die Informationen aus dem zurückgegebenen Retry-After Header nutzen, um den Zeitpunkt des Retry zu bestimmen.
    9. Ist der Download von Update-Paketen für den Konnektor abgeschlossen, MUSS der Konnektor darüber via
    TUC_KON_256 „Systemereignis absetzen“ {
            topic = „KSR/UPDATE/KONNEKTOR_DOWNLOAD_END“;
            eventType = Op;     
            severity = Info;     
            parameters  = (<Param>)}    
    informieren. Je heruntergeladenem FW-Paket MUSS <Param> mit folgenden Werten belegt sein:    
    <Param> =     „ProductVendorID= $UpdateInformation/ProductVendorID;
                         ProductCode= $UpdateInformation/ProductCode;
                         ProductName=$UpdateInformation/ProductName;
                         FirmwareVersion=$UpdateInformation/Firmware/FWVersion;
                         Deadline=$UpdateInformation/DeploymentInformation/Deadline;
                         FWPriority=$UpdateInformation/Firmware/FWPriority;
                         FirmwareReleaseNotes
                                         =$UpdateInformation/Firmware/FirmwareReleaseNotes“
    1. Sofern MGM_KSR_AUTODOWNLOAD = Enabled, SOLL der Konnektor bei Update-Paketen, die Kartenterminals betreffen, pro KT-Modell das Updatepaket mit der höchsten FirmwareVersion über I_KSRS_Download::get_Updates herunterladen, falls das Update-Paket nicht bereits von einem vorherigen Download auf dem Konnektor vorhanden ist.
    2. Sofern I_KSRS_Download::get_Updates den http Status Code 503 Server Unavailable zurückgibt, MUSS der Konnektor die Informationen aus dem zurückgegebenen Retry-After Header nutzen, um den Zeitpunkt des Retry zu bestimmen.

    Der Konnektor MUSS immer nur die neusten Update-Pakete für eine Nutzung vorhalten. Eventuell vorhandene ältere, nicht genutzte Update-Pakete KÖNNEN überschrieben werden.
    Nach einem erfolgreichen Download DÜRFEN die Namen der Dateien eines Update-Paketes beim Abspeichern NICHT verändert werden. <=

    TIP1-A_7220

    Der Konnektor KANN für den Download von Update-Paketen über I_KSRS_Download::get_Updates die Option Range Requests [RFC7233#3.1] zur Fortsetzung von unterbrochenen Transfers nutzen. <=

    TIP1-A_4837

    Die Administrationsoberfläche des KSR-Clients MUSS dem Administrator eine Übersichtseite anbieten, die einen Geräteeintrag für den Konnektor selbst, sowie eine Liste von Geräteeinträgen für jedes Kartenterminal (CT) aus CTM_CT_LIST mit CT.IS_PHYSICAL=Ja und CT.CORRELATION>=gepairt enthält.

    Der Administrator MUSS die Liste der Kartenterminals nach Kartenterminalmodellen gruppieren können (gleiche Werte für ProductVendorID, ProductCode, HardwareVersion und FirmwareVersion).

    Je Geräteeintrag MÜSSEN die über „Automatische Prüfung und Download von Update-Paketen“ ermittelten listUpdatesResponse bereitstehen.

    Je Geräteeintrag MUSS die Version der aktuell installierten Software dargestellt werden. Sind Bestandteile der installierten Software unabhängig aktualisierbar, so MUSS für jedes der Bestandteile die Version angezeigt werden.

    Der Administrator MUSS eine Aktualisierung aller listUpdatesResponse über TUC_KON_282 „UpdateInformationen beziehen“ auslösen können.

    Geräteeinträge, die über listUpdatesResponse mit neuerer Firmwareversion als das zugehörige Gerät verfügen, MÜSSEN hervorgehoben werden.

    Je Geräteeintrag MUSS die Zugehörigkeit der installierten Software und der Software-Updates zum Online-Produktivbetrieb oder zu einer Erprobung (inklusive Name der Erprobung) dargestellt werden.

    <=

    TIP1-A_4838

    Für alle Geräteeinträge MUSS der Administrator zu den listUpdatesResponse sowohl die FirmwareGroupReleaseNotes als auch jedes enthaltene UpdateInformation-Element einsehen können. Dazu MUSS der Konnektor

    <=

    TIP1-A_4839-01

    Der Administrator MUSS in der Übersichtsliste einzelne Geräteeinträge bzw. Gruppen mit der jeweils anzuwendenden UpdateInformation für die Durchführung eines Updates markieren können.
    Alternativ MUSS der Administrator neben der Markierung je Geräteeintrag bzw. Gruppe Update-Pakete lokal einspielen können (etwa durch ein Upload- bzw. Download-Interface in der Administrationsoberfläche).
    Je Geräteeintrag MUSS der Administrator einen individuellen Ausführungszeitpunkt für die Durchführung des Updates einstellen können.
    Der Administrator MUSS für den Geräteeintrag Konnektor festlegen können, ob dieses Update erst gestartet werden darf, wenn zuvor alle festgelegten KT-Updates erfolgreich durchlaufen wurden.
    Der Administrator MUSS zu jeder Zeit die gerätebezogene Festlegung für ein Update ändern bzw. löschen können, sofern dieses konkrete Update noch nicht begonnen wurde.
    Je Geräteeintrag MUSS der Administrator automatische Softwareupdates aktivieren und deaktivieren können.
    <=

    TIP1-A_4840-01

    Der Administrator MUSS für die Liste der markierten Geräteeinträge ein gesammeltes Update auslösen können. Dieses MUSS nach folgendem Muster ablaufen:

    1. Alle Kartenterminaleinträge abarbeiten. Pro markiertem Kartenterminal:
    1. Sofern die KonnektorUpdate-Abhängigkeit von KT-Updates nicht gesetzt wurde oder wenn alle vorgesehenen Kartenterminal-Updates durchgeführt wurden, MUSS das Konnektor-Updates mittels TUC_KON_280 „Konnektoraktualisierung durchführen“ wie folgt begonnen werden:
    Wenn der Administrator ein Erprobungs-Update zur Installation auswählt, MUSS er über einen Warnhinweis darüber informiert werden,
    dass, falls die Institution oder Organisation des Gesundheitswesens nicht an der Erprobung teilnimmt und dennoch das Update installiert wird, es zu funktionalen Einschränkungen des Konnektors kommen kann. <=

    A_18390

    Wenn für mindestens ein Gerät das automatische Softwareupdate aktiviert ist, MUSS der Konnektor zur MGM_KSR_AUTO_UPDATE_TIME die Updates nach folgendem Muster durchführen:

    <=

    A_18391

    Sofern der Konnektor zu MGM_KSR_AUTO_UPDATE_TIME nicht in Betrieb war, DÜRFEN die automatischen Updates später NICHT nachgeholt werden. <=

    A_18779

    Wenn mit einem Update erstmalig MGM_KSR_AUTO_UPDATE=Enabled aktiv wird, MUSS der Konnektorhersteller über das entsprechende KSR-Paket den Admin an der Konnektor Oberfläche darauf hinweisen, dass mit diesem Update der automatische Softwareupdate aktiv wird.
    <=

    A_20531

    Der Konnektor MUSS eine Bestandsnetze.xml mit einer Größe von mindestens 3 MByte und 2000 Netzen (XML Element <Network>) verarbeiten können. <=

    4.3.11 Konnektorstatus

    TIP1-A_5542

    Der Konnektor MUSS an der Managementschnittstelle eine Funktion anbieten, die es ermöglicht die Erreichbarkeit von Systemen durch Eingabe der IP-Adresse oder des FQDN zu prüfen. Das Ergebnis des Tests MUSS angezeigt werden.

    <=

    A_23276

    Der Konnektor MUSS dem Administrator an der Management-Oberfläche automatisch die Erreichbarkeit und die FQDNs von folgenden Systemen und ggf. ihren Backupservern anzeigen:

    <=

    4.4 Hardware-Merkmale des Konnektors

    TIP1-A_4841

    Der Konnektor MUSS sowohl in seiner Stromversorgung als auch in seinen restlichen Hardwarekomponenten auf einen 24x7-Dauerbetrieb ausgelegt sein.

    Der Hersteller DARF NICHT davon ausgehen oder gar in seiner Guidance darauf verweisen, dass der Konnektor mehrere Stunden am Tag nicht betrieben wird.

    <=

    Diese Anforderung verlangt keinen Schutz gegen Stromausfall in den Betriebsräumen.

    TIP1-A_4842

    Jeder Konnektor, der als Appliance (dezidierte, geschlossene Kombination aus spezifischer Hard- und Software) ausgeprägt ist, MUSS über eine fälschungssichere Gehäuseversiegelung verfügen. Die Versiegelung MUSS so angebracht werden, dass eine Öffnung des Gehäuses nicht ohne Beschädigung des Siegels erfolgen kann.

    Der Konnektor MUSS die Umsetzung entsprechend der Festlegungen für das Kartenterminal nach der TR-03120 [BSI TR-03120], Kapitel bzgl. Gehäuseversiegelung 9 vornehmen.

    Die optische Gestaltung der Siegel ist herstellerspezifisch.

    <=

    Die Prüfung auf Einhaltung der Versiegelungsvorgaben erfolgt nicht im Rahmen der CC-Evaluierung, sondern im Zuge der Prüfung auf funktionale Eignung.

    TIP1-A_4843

    Im Betrieb MUSS der Zustand des Konnektors erkennbar sein. Zur Anzeige des Betriebszustandes des Konnektors SOLL es eine Signaleinrichtung (z. B. über Status-LEDs) am Konnektor geben. Falls keine Signalvorrichtung am Konnektorgehäuse verwendet wird MUSS es eine softwareseitige Lösung über das Managementinterface geben. Bei verbauter Hardware-Signalgebung KANN eine softwareseitige Lösung zusätzlich angeboten werden.
    Es MÜSSEN mindestens folgende angezeigt werden:

    Es SOLLEN folgende Zustände angezeigt werden:
    <=

    TIP1-A_4844-02

    Der Konnektor MUSS mindestens zwei Ethernetinterfaces nach [IEEE802.3] als physikalische Schnittstellen zur Verfügung stellen.
    <=

    TIP1-A_4845

    Als normaler Einsatzort wird für den Konnektor ein Büroraum angenommen. Der Konnektor MUSS die in Tabelle TAB_KON_671 aufgeführten Anforderungen erfüllen, welche unter der Annahme des normalen Einsatzortes erhoben werden.

    Tabelle 386: TAB_KON_671 Anforderungen Klima

    Prüfung Klima
    Trockene Wärme (Dry Heat) nach DIN EN 60068-2-2 Methode Bb wird für die Bedingungen als obere Lagertemperatur von 55°C und einer Beanspruchungsdauer von 16 h geprüft und die Funktionsfähigkeit MUSS bestätigt werden.
    Kälte (Cold) nach DIN EN 60068-2-1 Methode Ab wird für die Bedingungen als untere Lagertemperatur von -10°C und einer Beanspruchungsdauer von 16 h geprüft und die Funktionsfähigkeit MUSS bestätigt werden.
    Nach den beiden oben genannten Belastungen durch extreme Lagertemperaturen und der Nachbehandlungsdauer von 1 h MUSS die Funktionsfähigkeit des Konnektors gewährleistet sein, was durch Funktionsprüfungen nachzuweisen ist.
    Die Funktionsfähigkeit im Betrieb MUSS bei einer oberen Temperatur von 40°C über eine Dauer von 24 h gewährleistet sein. Dies wird für den Konnektor durch Prüfung nach DIN EN 60068-2-2 Methode Bb bei gleichzeitigen Funktionsprüfungen nachgewiesen.

    <=

    TIP1-A_4846

    Die durch Vibrationen und mechanische Schockbelastungen auftretenden Belastungen MÜSSEN vom Konnektor schadensfrei gemäß IEC 68-2 Methode nach den Anforderungen aus TAB_KON_672 absolviert, geprüft und nachgewiesen werden.


    Tabelle 387: TAB_KON_672 Anforderungen Vibration

    Prüfung Vibration
    Sinusförmige Schwingungstests (Vibration, sinusoidal) nach DIN EN 60068-2-6 Methode Fc in drei senkrecht stehenden Achsen in einem Frequenzbereich von 2 Hz bis 200 Hz üblicherweise 1 h je Achse MÜSSEN erfolgreich nachgewiesen werden. Bis zu einer Frequenz von 9 Hz wird dabei mit einer konstanten Amplitude von 1,5 mm belastet, darüber bis zur oberen Frequenz wird mit einer konstanten Beschleunigung von 5 m/s2 (0,5 g) belastet.
    Es MÜSSEN mechanische Schockprüfungen (Shock) nach DIN EN 60068-2-27 Methode Ea in drei senkrecht stehenden Achsen (sechs Richtungen) erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 3 positiven und 3 negativen Schocks mit 150 m/s2 (15 g) Amplitude und einer Dauer von 11 ms belastet.
    Dauerschocktests (Bump) nach DIN EN 60068-2-29 Methode Eb in drei senkrecht stehenden Achsen mit halbsinusförmigen Schocks MÜSSEN erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 1000 positiven und 1000 negativen Schocks mit 100 m/s2 (10 g) Amplitude und einer Dauer von 16 ms belastet.

    <=

    TIP1-A_4846-02

    Die durch Vibrationen und mechanische Schockbelastungen auftretenden Belastungen MÜSSEN vom Konnektor schadensfrei gemäß IEC 68-2 Methode nach den Anforderungen aus TAB_KON_672 absolviert, geprüft und nachgewiesen werden.


    Tabelle 388: TAB_KON_672 Anforderungen Vibration

    Prüfung Vibration
    Sinusförmige Schwingungstests (Vibration, sinusoidal) nach DIN EN 60068-2-6 Methode Fc in drei senkrecht stehenden Achsen in einem Frequenzbereich von 2 Hz bis 200 Hz üblicherweise 1 h je Achse MÜSSEN erfolgreich nachgewiesen werden. Bis zu einer Frequenz von 9 Hz wird dabei mit einer konstanten Amplitude von 1,5 mm belastet, darüber bis zur oberen Frequenz wird mit einer konstanten Beschleunigung von 5 m/s2 (0,5 g) belastet.
    Es MÜSSEN mechanische Schockprüfungen (Shock) nach DIN EN 60068-2-27 Methode Ea in drei senkrecht stehenden Achsen (sechs Richtungen) erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 3 positiven und 3 negativen Schocks mit 150 m/s2 (15 g) Amplitude und einer Dauer von 11 ms belastet.
    Dauerschocktests (Bump) nach DIN EN 60068-2-27 Methode Eb in drei senkrecht stehenden Achsen mit halbsinusförmigen Schocks MÜSSEN erfolgreich nachgewiesen werden. Es wird dabei für jede Achse mit 1000 positiven und 1000 negativen Schocks mit 100 m/s2 (10 g) Amplitude und einer Dauer von 16 ms belastet.

    <=

    5 Anhang A – Verzeichnisse

    5.1 Abkürzungen

    Kürzel
    Erläuterung
    AMTS
    Arzneimitteltherapiesicherheit
    APPL DO
    Application Label Data Object
    CC
    Common Criteria
    DHCP
    Dynamic Host Configuration Protocol
    DNS
    Domain Name Service
    DO
    Datenobjekt
    DSL
    Digital Subscriber Line
    ECC
    Elliptic Curve Cryptography
    EVG
    Evaluierungsgegenstand
    gSMC-K
    Security Module Card Typ K (Konnektor)
    gSMC-KT
    Security Module Card Typ KT (Kartenterminal)
    HBA
    Heilberufsausweis
    HSM-B
    Hardware Security Module Typ B
    IAG
    Internet Access Gateway
    ID
    Identifier
    ISP
    Internet Service Provider
    KT
    Kartenterminal
    KVK
    Krankenversichertenkarte
    LAN
    Local Area Network
    MTOM
    Message Transmission Optimization Mechanism
    NFDM
    Notfalldatenmanagement
    NK
    Netzkonnektor
    NTP
    Netzwork Time Protokoll
    OCSP
    Online Certificate Status Protocol
    OID
    Object Identifier
    PIN
    Personal
    PKI
    Public Key Infrastructure
    PP
    Protection Profile
    PU
    Produktivumgebung
    PUK
    Personal Unblocking Key
    QES
    Qualifizierte elektronische Signatur
    RU
    Referenzumgebung
    SIS
    Secure Internet Service
    SMC-B
    Security Module Card Typ B
    SMTBD DO
    SICCT Message-To-Be-Displayed Data Object
    SOAP
    Standard für die Kommunikation innerhalb der WEB-Services
    TI
    Telematikinfrastruktur
    TLS
    Transport Layer Security
    TSF
    TOE Security Functionality
    TU
    Testumgebung
    TUC
    Technischer Use Case
    URL
    Uniform Resource Locator
    VPN
    Virtual Private Network
    VSDM
    Versichertenstammdatenmanagement
    VZD
    Verzeichnisdienst
    WAN
    Wide Area Network
    WANDA Basic Weitere Anwendungen für den Datenaustausch ohne Nutzung der TI oder derer kryptografischen Identitäten 
    WANDA Smart Weitere Anwendungen für den Datenaustausch mit Nutzung der TI oder derer kryptografischen Identitäten für eigene Anwendungszwecke
    XML
    Extensible Markup Language
    ZD
    Zertifizierungsdienst
    ZOD 2.0
    Zahnärzte Online Deutschland 2.0

    5.2 Glossar

    Begriff
    Erläuterung
    Funktionsmerkmal
    Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems.

    Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

    5.3 Abbildungsverzeichnis

  • Abbildung 1: PIC_KON_116 Schnittstellen des Konnektors von und zu anderen Produkttypen
  • Abbildung 2: PIC_KON_117 Logische Zerlegung des Konnektors in Anwendungs- und Netzkonnektor
  • Abbildung 3: PIC_KON_107 XML-Struktur des Status-Elements einer SOAP-Antwort
  • Abbildung 4: PIC_Kon_100 Informationsmodell des Konnektors
  • Abbildung 5: PIC_KON_101 Aufrufkontext der Operation
  • Abbildung 6: PIC_KON_118 Aktivitätsdiagramm zu „TUC_KON_000 Prüfe Zugriffsberechtigung“
  • Abbildung 7: PIC_KON_071 Korrelationszustände eines eHealth-KT
  • Abbildung 8: PIC_KON_110 Aktivitätsdiagramm zu „Beginne Kartenterminalsitzung“
  • Abbildung 9: PIC_KON_057 Aktivitätsdiagramm zu „PaireKartenterminal“
  • Abbildung 10: PIC_KON_111 Aktivitätsdiagramm zu „PIN verifizieren“
  • Abbildung 11: PIC_KON_022 Grundsätzlicher Aufbau der Ereignisnachricht
  • Abbildung 12: PIC_KON_112 Aktivitätsdiagramm zu „Systemereignis absetzen“
  • Abbildung 13: PIC_KON_058 Aktivitätsdiagramm „Daten hybrid verschlüsseln“
  • Abbildung 14: PIC_KON_059 Aktivitätsdiagramm „Daten hybrid entschlüsseln“
  • Abbildung 15: PIC_KON_103 Use Case Diagramm Signaturdienst (nonQES)
  • Abbildung 16: PIC_KON_104 Use Case Diagramm Signaturdienst (QES)
  • Abbildung 17: PIC_KON_102 Use Case Diagramm Signaturdienst (Komfortsignatur)
  • Abbildung 18: PIC_KON_113 Aktivitätsdiagramm zu „QES Signaturen erstellen“
  • Abbildung 19: PIC_KON_114 Aktivitätsdiagramm zu „Dokument QES signieren“
  • Abbildung 20: PIC_KON_118 Aufbau und Struktur der Protokolldateien für Plattform und Fachmodule
  • Abbildung 21: PIC_KON_115 Kommunikationsregeln Konnektor
  • Abbildung 22: PIC_KON_105 Aktivitätsdiagramm Konnektoraktualisierung durchführen  
  • Abbildung 23: PIC_KON_120 Abbildung von CardSessions auf logische Kanäle
  • Abbildung 24: Szenario einer einfachen Installation
  • Abbildung 25: Szenario einer Installation mit mehreren Behandlungsräumen
  • Abbildung 26: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur
  • Abbildung 27: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur mit existierendem Router
  • Abbildung 28: Szenario mit zentral gesteckten HBA und SMC-B
  • Abbildung 29: Szenario mit zentralem Primärsystem als Clientsystem
  • Abbildung 30: Szenario für den Zugriff
  • Abbildung 31:  Standalone-Szenario mit physischer Trennung im Konnektor
  • 5.4 Tabellenverzeichnis

  • Tabelle 1 Fehlercodes TAB_KON_890 Mindestanforderungen an Dokumente und Nachrichten
  • Tabelle 2 Fehlercodes TAB_KON_891 Unerlaubte Inhalte in Dokumenten und Nachrichten
  • Tabelle 3: TAB_KON_500 Wertetabelle Kartentypen
  • Tabelle 4: TAB_KON_856: Identitäten des Konnektors auf der gSMC-K
  • Tabelle 5: TAB_KON_503 Betriebszustand_Fehlerzustandsliste
  • Tabelle 6: TAB_KON_504 Ausführungserlaubnis für Dienste in kritischen Fehlerzuständen
  • Tabelle 7: TAB_KON_502 Fehlercodes „Betriebszustand“
  • Tabelle 8: TAB_KON_505 Konfigurationswerte Missbrauchserkennung
  • Tabelle 9: TAB_KON_852 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen
  • Tabelle 10: TAB_KON_865-01 Konfigurationsvarianten der Verbindungen zwischen Konnektor und Clientsystemen bei LDAP
  • Tabelle 11: TAB_KON_506-01 Konfigurationsparameter der Clientsystem-Authentisierung
  • Tabelle 12: TAB_KON_812 Umgebungsabhängige Konfigurationsparameter
  • Tabelle 13: TAB_KON_507 Informationsmodell Entitäten
  • Tabelle 14: TAB_KON_508 Informationsmodell Attribute
  • Tabelle 15: TAB_KON_509 Informationsmodell Entitätenbeziehungen
  • Tabelle 16: TAB_KON_510 Informationsmodell Constraints
  • Tabelle 17: TAB_KON_511-01 – TUC_KON_000 „Prüfe Zugriffsberechtigung“
  • Tabelle 18: TAB_KON_512 Zugriffsregeln Beschreibung
  • Tabelle 19: TAB_KON_513 Zugriffsregeln Regelzuordnung
  • Tabelle 20: TAB_KON_514-01 Zugriffsregeln Definition
  • Tabelle 21: TAB_KON_515 Fehlercodes TUC_KON_000 „Prüfe Zugriffsberechtigung“
  • Tabelle 22: TAB_KON_143 – TUC_KON_080 „Dokument validieren“
  • Tabelle 23: TAB_KON_144 Fehlercodes TUC_KON_080 „Dokument validieren“
  • Tabelle 24: TAB_KON_516 Basisanwendung Dienstverzeichnisdienst
  • Tabelle 25: TAB_KON_517 Schemabeschreibung Produktinformation (ProductInformation.xsd)
  • Tabelle 26: TAB_KON_518 Schemabeschreibung Serviceinformation (Serviceinformation.xsd)
  • Tabelle 27: TAB_KON_519 - TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“
  • Tabelle 28: TAB_KON_520 Fehlercodes TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“
  • Tabelle 29: TAB_KON_521 Schnittstelle der Basisanwendung Dienstverzeichnisdienst
  • Tabelle 30: TAB_KON_522 Parameterübersicht des Kartenterminaldienstes
  • Tabelle 31: TAB_KON_785 Erlaubte SICCT-Kommandos bei CT.CONNECTED=Nein
  • Tabelle 32: TAB_KON_727 Terminalanzeigen beim Anfordern und Auswerfen von Karten
  • Tabelle 33: TAB_KON_039 – TUC_KON_050 „Beginne Kartenterminalsitzung“
  • Tabelle 34: TAB_KON_523 Fehlercodes TUC_KON_050 „Beginne Kartenterminalsitzung“
  • Tabelle 35: TAB_KON_524 – TUC_KON_054 „Kartenterminal hinzufügen“
  • Tabelle 36: TAB_KON_525 Fehlercodes TUC_KON_054 „Kartenterminal hinzufügen“
  • Tabelle 37: TAB_KON_041 – TUC_KON_053 „Paire Kartenterminal“
  • Tabelle 38: TAB_KON_113 Fehlercodes TUC_KON_053 „Paire Kartenterminal“
  • Tabelle 39: TAB_KON_526 – TUC_KON_055 „Befülle CT-Object“
  • Tabelle 40: TAB_KON_112 – TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“
  • Tabelle 41: TAB_KON_114 Fehlercodes TUC_KON_051 „Mit Anwender über Kartenterminal interagieren“
  • Tabelle 42: TAB_KON_723 - TUC_KON_056 „Karte anfordern“
  • Tabelle 43: TAB_KON_724 Fehlercodes TUC_KON_056 „Karte anfordern“
  • Tabelle 44: TAB_KON_725 – TUC_KON_057 „Karte auswerfen“
  • Tabelle 45: TAB_KON_796 Fehlercodes TUC_KON_057 „Karte auswerfen“
  • Tabelle 46: TAB_KON_854 – TUC_KON_058 „Displaygröße ermitteln“
  • Tabelle 47: TAB_KON_855 Fehlercodes TUC_KON_058 „Displaygröße ermitteln“
  • Tabelle 48: TAB_KON_722 Basisdienst Kartenterminaldienst
  • Tabelle 49: TAB_KON_716 Operation RequestCard
  • Tabelle 50: TAB_KON_717 Ablauf RequestCard
  • Tabelle 51: TAB_KON_718 Fehlercodes „RequestCard“
  • Tabelle 52: TAB_KON_719 Operation EjectCard
  • Tabelle 53: TAB_KON_720 Ablauf EjectCard
  • Tabelle 54: TAB_KON_721 Fehlercodes Operation „EjectCard“
  • Tabelle 55: TAB_KON_527 Konfigurationswerte eines Kartenterminalobjekts
  • Tabelle 56: TAB_KON_528 Informationsparamter des Kartenterminaldienstes
  • Tabelle 57: TAB_KON_529 Anzeigewerte zu einem Kartenterminalobjekt
  • Tabelle 58: TAB_KON_530 Konfigurationswerte eines Kartenterminalobjekts
  • Tabelle 59: TAB_KON_531 Parameterübersicht des Kartendienstes
  • Tabelle 60: TAB_KON_090 Terminalanzeigen beim Eingeben der PIN am Kartenterminal
  • Tabelle 61: TAB_KON_734 – TUC_KON_001 „Karte öffnen“
  • Tabelle 62: TAB_KON_735 - TUC_KON_026
  • Tabelle 63: TAB_KON_824 Fehlercodes TUC_KON_026 „Liefere CardSession“
  • Tabelle 64: TAB_KON_087 – TUC_KON_012 „PIN verifizieren“
  • Tabelle 65: TAB_KON_089 Fehlercodes TUC_KON_012 „PIN verifizieren“
  • Tabelle 66: TAB_KON_736 – TUC_KON_019 „PIN ändern“
  • Tabelle 67: TAB_KON_093 Fehlercodes TUC_KON_019 „PIN ändern“
  • Tabelle 68: TAB_KON_236 – TUC_KON_021 „PIN entsperren“
  • Tabelle 69: TAB_KON_193 Fehlercodes TUC_KON_021 „PIN entsperren“
  • Tabelle 70 TAB_KON_532 – TUC_KON_022 „Liefere PIN-Status“
  • Tabelle 71: TAB_KON_091 Fehlercodes TUC_KON_022 „Liefere PIN-Status“
  • Tabelle 72: TAB_KON_240 - TUC_KON_027 „PIN-Schutz ein-/ausschalten”
  • Tabelle 73: TAB_KON_838 Mapping von pinRef auf ANW
  • Tabelle 74: TAB_KON_241 Fehlercodes TUC_KON_027 „PIN-Schutz ein/ausschalten“
  • Tabelle 75: TAB_KON_533 - TUC_KON_023 „Karte reservieren”
  • Tabelle 76: TAB_KON_534 Fehlercodes TUC_KON_023 „Karte reservieren“
  • Tabelle 77: TAB_KON_096 – TUC_KON_005 „Card-to-Card authentisieren”
  • Tabelle 78: TAB_KON_673 AuthMode für C2C
  • Tabelle 79: TAB_KON_674 Erlaubte Parameterkombinationen und resultierende CV-Zertifikate für C2C
  • Tabelle 80: TAB_KON_535 Fehlercodes TUC_KON_005 „Card-to-Card authentisieren“
  • Tabelle 81: TAB_KON_218 – TUC_KON_202 „LeseDatei“
  • Tabelle 82: TAB_KON_536 Fehlercodes TUC_KON_202 „LeseDatei“
  • Tabelle 83: TAB_KON_219 – TUC_KON_203 „SchreibeDatei“
  • Tabelle 84: TAB_KON_537 Fehlercodes TUC_KON_203 „Schreibe Datei“
  • Tabelle 85: TAB_KON_204 – TUC_KON_204 „LöscheDateiInhalt“
  • Tabelle 86: TAB_KON_785 Fehlercodes TUC_KON_204 „LöscheDateiInhalt“
  • Tabelle 87: TAB_KON_538 – TUC_KON_209 „LeseRecord“
  • Tabelle 88: TAB_KON_539 Fehlercodes TUC_KON_209 „LeseRecord“
  • Tabelle 89: TAB_KON_224 – TUC_KON_210 „SchreibeRecord“
  • Tabelle 90: TAB_KON_540 Fehlercodes TUC_KON_210 „SchreibeRecord“
  • Tabelle 91: TAB_KON_211 – TUC_KON_211 „LöscheRecordInhalt“
  • Tabelle 92: TAB_KON_786 Fehlercodes TUC_KON_211 „LöscheRecordInhalt“
  • Tabelle 93: TAB_KON_228 – TUC_KON_214 „FügeHinzuRecord“
  • Tabelle 94: TAB_KON_541 Fehlercodes TUC_KON_214 „FügeHinzuRecord“
  • Tabelle 95: TAB_KON_229 – TUC_KON_215 „SucheRecord“
  • Tabelle 96: TAB_KON_542 Fehlercodes TUC_KON_215 „SucheRecord“
  • Tabelle 97: TAB_KON_110 - TUC_KON_018 „eGK-Sperrung prüfen“
  • Tabelle 98: TAB_KON_239 Fehlercodes TUC_KON_018 „eGK-Sperrung prüfen“
  • Tabelle 99: TAB_KON_108 - TUC_KON_006 „Datenzugriffsaudit eGK schreiben“
  • Tabelle 100: TAB_KON_238 Fehlercodes TUC_KON_006 „Datenzugriffsaudit eGK schreiben“
  • Tabelle 101: TAB_KON_231 – TUC_KON_218 „Signiere“
  • Tabelle 102: TAB_KON_543 Fehlercodes TUC_KON_218 „Signiere“
  • Tabelle 103: TAB_KON_232 – TUC_KON_219 „Entschlüssele“
  • Tabelle 104: TAB_KON_210 Fehlercodes TUC_KON_219 „Entschlüssele“
  • Tabelle 105: TAB_KON_215 TUC_KON_200 „SendeAPDU“
  • Tabelle 106: TAB_KON_216 Fehlercodes TUC_KON_200 „SendeAPDU“
  • Tabelle 107: TAB_KON_737 – TUC_KON_024 „Karte zurücksetzen“
  • Tabelle 108: TAB_KON_544 Fehlercodes TUC_KON_024 „Karte zurücksetzen“
  • Tabelle 109: TAB_KON_230 – TUC_KON_216 „LeseZertifikat“
  • Tabelle 110: TAB_KON_209 Fehlercodes TUC_KON_216 „LeseZertifikat“
  • Tabelle 111: TAB_KON_827 TUC_KON_036 „LiefereFachlicheRolle“
  • Tabelle 112: TAB_KON_829 Fehlercodes TUC_KON_036 „LiefereFachlicheRolle“
  • Tabelle 113: TAB_KON_038 Basisanwendung Karten- und Kartenterminaldienst
  • Tabelle 114: TAB_KON_047 Operation VerifyPin
  • Tabelle 115: TAB_KON_738 Ablauf VerifyPin
  • Tabelle 116: TAB_KON_545 Fehlercodes „VerifyPin“
  • Tabelle 117: TAB_KON_049 Operation ChangePin
  • Tabelle 118: TAB_KON_546 Ablauf ChangePin
  • Tabelle 119: TAB_KON_547 Fehlercodes „ChangePin“
  • Tabelle 120: TAB_KON_051 Operation GetPinStatus
  • Tabelle 121: TAB_KON_548 Ablauf GetPinStatus
  • Tabelle 122: TAB_KON_549 Fehlercodes „GetPinStatus“
  • Tabelle 123: TAB_KON_053 Operation UnblockPin
  • Tabelle 124: TAB_KON_550 Ablauf UnblockPIN
  • Tabelle 125: TAB_KON_551 Fehlercodes „UnblockPin“
  • Tabelle 126: TAB_KON_242 Operation EnablePin
  • Tabelle 127: TAB_KON_243 Ablauf EnablePin
  • Tabelle 128: TAB_KON_244 Fehlercodes „EnablePin“
  • Tabelle 129: TAB_KON_245 Operation DisablePin
  • Tabelle 130: TAB_KON_246 Ablauf DisablePin
  • Tabelle 131: TAB_KON_247 Fehlercodes „DisablePin“
  • Tabelle 132: TAB_KON_554 Konfiguration des Kartendienstes
  • Tabelle 133: TAB_KON_555 - TUC_KON_025 „Initialisierung Kartendienst“
  • Tabelle 134: TAB_KON_030 Ereignisnachricht
  • Tabelle 135: TAB_KON_556 - TUC_KON_256 „Systemereignis absetzen“
  • Tabelle 136: TAB_KON_557 Fehlercodes TUC_KON_256 „Systemereignis absetzen“
  • Tabelle 137: TAB_KON_558 – TUC_KON_252 „Liefere KT_Liste“
  • Tabelle 138: TAB_KON_559 – TUC_KON_253 „Liefere Karten_Liste“
  • Tabelle 139: TAB_KON_560 Fehlercodes TUC_KON_253 „Liefere Karten_Liste“
  • Tabelle 140: TAB_KON_561 - TUC_KON_254 „Liefere Ressourcendetails“
  • Tabelle 141: TAB_KON_562 Fehlercodes TUC_KON_254 „Liefere Ressourcendetails“
  • Tabelle 142 TAB_KON_029 Basisanwendung Systeminformationsdienst
  • Tabelle 143: TAB_KON_563 Operation GetCardTerminals
  • Tabelle 144: TAB_KON_564 Ablauf GetCardTerminals
  • Tabelle 145: TAB_KON_823 Fehlercodes „GetCardTerminals“
  • Tabelle 146: TAB_KON_565 Operation GetCards
  • Tabelle 147: TAB_KON_566 Ablauf GetCards
  • Tabelle 148: TAB_KON_567 Fehlercodes „GetCards“
  • Tabelle 149: TAB_KON_568 Operation GetResourceInformation
  • Tabelle 150: TAB_KON_569 Ablauf GetResourceInformation
  • Tabelle 151: TAB_KON_570 Fehlercodes „GetResourceInformation“
  • Tabelle 152: TAB_KON_571 Operation Subscribe
  • Tabelle 153: TAB_KON_572 Ablauf Subscribe
  • Tabelle 154 TAB_KON_573 Fehlercodes „Subscribe“
  • Tabelle 155: TAB_KON_574 Operation Unsubscribe
  • Tabelle 156: TAB_KON_575 Ablauf Unsubscribe
  • Tabelle 157: TAB_KON_576 Fehlercodes „Unsubscribe“
  • Tabelle 158: TAB_KON_792 Operation RenewSubscriptions
  • Tabelle 159: TAB_KON_793 Ablauf RenewSubscriptions
  • Tabelle 160: TAB_KON_794 Fehlercodes „RenewSubscriptions“
  • Tabelle 161: TAB_KON_577 Operation GetSubscription
  • Tabelle 162: TAB_KON_578 Ablauf GetSubscription
  • Tabelle 163: TAB_KON_579 Fehlercodes „GetSubscription“
  • Tabelle 164: TAB_KON_580 Konfigurationswerte des Systeminformationsdienstes (Administrator)
  • Tabelle 165: TAB_KON_581 Verschlüsselungsdienst-Operationen für EVT_MONITOR_OPERATIONS
  • Tabelle 166: TAB_KON_747 KeyReference für Encrypt-/DecryptDocument
  • Tabelle 167: TAB_KON_859 Werteliste und Defaultwert des Parameters crypt bei hybrider Verschlüsselung
  • Tabelle 168: TAB_KON_739 - TUC_KON_070 „Daten hybrid verschlüsseln“
  • Tabelle 169: TAB_KON_073 Vorgaben zum Format verschlüsselter XML-Dokumente
  • Tabelle 170: TAB_KON_740 Fehlercodes TUC_KON_070 „Daten hybrid verschlüsseln“
  • Tabelle 171: TAB_KON_140 – TUC_KON_071 „Daten hybrid entschlüsseln“
  • Tabelle 172: TAB_KON_142 Fehlercodes TUC_KON_071 „Daten hybrid entschlüsseln“
  • Tabelle 173: TAB_KON_741 – TUC_KON_072 „Daten symmetrisch verschlüsseln“
  • Tabelle 174: TAB_KON_742 Fehlercodes TUC_KON_072 „Daten symmetrisch verschlüsseln“
  • Tabelle 175: TAB_KON_743 - TUC_KON_073 „Daten symmetrisch entschlüsseln“
  • Tabelle 176: TAB_KON_744 Fehlercodes TUC_KON_073 „Daten symmetrisch entschlüsseln“
  • Tabelle 177: TAB_KON_860 – TUC_KON_075 „Symmetrisch verschlüsseln“
  • Tabelle 178: TAB_KON_861 - TUC_KON_076 „Symmetrisch entschlüsseln“
  • Tabelle 179: TAB_KON_745 Basisdienst Verschlüsselungsdienst
  • Tabelle 180: TAB_KON_071 Operation EncryptDocument
  • Tabelle 181: TAB_KON_746 Ablauf EncryptDocument
  • Tabelle 182: TAB_KON_141 Fehlercodes „EncryptDocument“
  • Tabelle 183: TAB_KON_075 Operation DecryptDocument
  • Tabelle 184: TAB_KON_076 Ablauf DecryptDocument
  • Tabelle 185: TAB_KON_145 Fehlercodes „DecryptDocument“
  • Tabelle 186: TAB_KON_582 – Signaturverfahren Dokumentensignatur
  • Tabelle 187: TAB_KON_778 – Einsatzbereich der Signaturvarianten für XAdES, CAdES und PAdES
  • Tabelle 188: TAB_KON_583 – Default-Signaturverfahren
  • Tabelle 189: TAB_KON_584 nonQES-Operationen für EVT_MONITOR_OPERATIONS
  • Tabelle 190: TAB_KON_900 Zertifikate und private Schlüssel für Signaturerstellung und Signaturprüfung (QES und nonQES)
  • Tabelle 191: TAB_KON_862-01 Werteliste und Defaultwert des Parameters crypt bei QES-Erzeugung
  • Tabelle 192: TAB_KON_863 Werteliste und Defaultwert des Parameters crypt bei nonQES-Erzeugung
  • Tabelle 193: TAB_KON_748 - TUC_KON_155 „Dokumente zur Signatur vorbereiten“
  • Tabelle 194: TAB_KON_586 Fehlercodes TUC_KON_155 „Dokumente zur Signatur vorbereiten“
  • Tabelle 195: TAB_KON_749 – TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
  • Tabelle 196: TAB_KON_587 Fehlercodes TUC_KON_165 „Signaturvoraussetzungen für nonQES prüfen“
  • Tabelle 197: TAB_KON_750 – TUC_KON_166 „nonQES Signaturen erstellen“
  • Tabelle 198: TAB_KON_120 Fehlercodes TUC_KON_166 „nonQES Signaturen erstellen“
  • Tabelle 199: TAB_KON_751 – TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
  • Tabelle 200: TAB_KON_588 Fehlercodes TUC_KON_152 „Signaturvoraussetzungen für QES prüfen“
  • Tabelle 201: TAB_KON_752 – TUC_KON_154 „QES Signaturen erstellen"
  • Tabelle 202: TAB_KON_126 Fehlercodes TUC_KON_154 „QES Signaturen erstellen“
  • Tabelle 203: TAB_KON_293 - TUC_KON_168 „Einzelsignatur QES erstellen“
  • Tabelle 204: TAB_KON_590 Fehlercodes TUC_KON_168 „Einzelsignatur QES erstellen“
  • Tabelle 205: TAB_KON_870 – TUC_KON_158 „Komfortsignaturen erstellen"
  • Tabelle 206: TAB_KON_873 Fehlercodes TUC_KON_158 „Komfortsignaturen erstellen“
  • Tabelle 207: TAB_KON_753 – TUC_KON_160 „Dokumente nonQES signieren“
  • Tabelle 208: TAB_KON_127 Fehlercodes TUC_KON_160 „Dokumente nonQES signieren“
  • Tabelle 209: TAB_KON_753 – TUC_KON_160 „Dokumente nonQES signieren“
  • Tabelle 210: TAB_KON_127 Fehlercodes TUC_KON_160 „Dokumente nonQES signieren“
  • Tabelle 211: TAB_KON_121 - TUC_KON_161 „nonQES Dokumentsignatur prüfen“
  • Tabelle 212: TAB_KON_124 Fehlercodes TUC_KON_161 „nonQES Dokumentensignatur prüfen“
  • Tabelle 213: TAB_KON_754 Übersicht Status für Prüfung einer Dokumentensignatur
  • Tabelle 214: TAB_KON_786 Übersicht unterstützte Zertifikatstyp-OIDs
  • Tabelle 215: TAB_KON_430 – TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“
  • Tabelle 216: TAB_KON_431 Fehlercodes TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“
  • Tabelle 217: TAB_KON_755 – TUC_KON_150 „Dokumente QES signieren“
  • Tabelle 218: TAB_KON_128 Fehlercodes TUC_KON_150 „Dokument QES signieren“
  • Tabelle 219: TAB_KON_192 Verhalten des Konnektors beim Abbruch einer Stapelsignatur
  • Tabelle 220: TAB_KON_591 - TUC_KON_151 „QES-Dokumentensignatur prüfen“
  • Tabelle 221: TAB_KON_592 Fehlercodes TUC_KON_151 „QES Dokumentensignatur prüfen“
  • Tabelle 222: TAB_KON_593 Übersicht Status für Prüfung einer Dokumentensignatur
  • Tabelle 223: TAB_KON_871 – TUC_KON_170 „Dokumente mit Komfort signieren“
  • Tabelle 224: TAB_KON_872 Fehlercodes TUC_KON_170 „Dokumente mit Komfort signieren“
  • Tabelle 225: TAB_KON_883 – TUC_KON_171 „Komfortsignatur einschalten“
  • Tabelle 226: TAB_KON_886 Fehlercodes TUC_KON_171 „Komfortsignatur einschalten“
  • Tabelle 227: TAB_KON_884 – TUC_KON_172 „Komfortsignatur ausschalten“
  • Tabelle 228: TAB_KON_887 Fehlercodes TUC_KON_172 „Komfortsignatur ausschalten“
  • Tabelle 229: TAB_KON_885 – TUC_KON_173 „Liefere Signaturmodus“
  • Tabelle 230: TAB_KON_888 Fehlercodes TUC_KON_173 „Liefere Signaturmodus“
  • Tabelle 231: TAB_KON_197 Basisdienst Signaturdienst (nonQES und QES)
  • Tabelle 232: TAB_KON_065 Operation SignDocument (nonQES und QES)
  • Tabelle 233: TAB_KON_756 Ablauf Operation SignDocument (nonQES und QES)
  • Tabelle 234: TAB_KON_757 Fehlercodes „SignDocument (nonQES und QES)“
  • Tabelle 235: TAB_KON_066 Operation VerifyDocument (nonQES und QES)
  • Tabelle 236: TAB_KON_760 Ablauf Operation VerifyDocument (nonQES und QES)
  • Tabelle 237: TAB_KON_761 Fehlercodes „VerifyDocument (nonQES und QES)“
  • Tabelle 238: TAB_KON_840 Operation StopSignature
  • Tabelle 239: TAB_KON_841 Ablauf Operation StopSignature
  • Tabelle 240: TAB_KON_842 Fehlercodes „StopSignature“
  • Tabelle 241: TAB_KON_843 Operation GetJobNumber
  • Tabelle 242: TAB_KON_844 Ablauf Operation GetJobNumber
  • Tabelle 243: TAB_KON_845 Fehlercodes „GetJobNumber“
  • Tabelle 244: TAB_KON_874 ActivateComfortSignature
  • Tabelle 245: TAB_KON_877 Ablauf ActivateComfortSignature
  • Tabelle 246: TAB_KON_879 Fehlercodes ActivateComfortSignature
  • Tabelle 247: TAB_KON_875 DeactivateComfortSignature
  • Tabelle 248: TAB_KON_878 Ablauf DeactivateComfortSignature
  • Tabelle 249: TAB_KON_880 Fehlercodes DeactivateComfortSignature
  • Tabelle 250: TAB_KON_876 GetSignatureMode
  • Tabelle 251: TAB_KON_882 Ablauf GetSignatureMode
  • Tabelle 252: TAB_KON_881 Fehlercodes GetSignatureMode
  • Tabelle 253: TAB_KON_596 Konfigurationswerte des Signaturdienstes (Administrator)
  • Tabelle 254: TAB_KON_853- intendedKeyUsage bei Zertifikatsprüfung
  • Tabelle 255: TAB_KON_858 Kartenobjekt in Abhängigkeit vom kryptographischen Verfahren
  • Tabelle 256: TAB_KON_825 Fehlercodes „TLS-Verbindungsaufbau zum TSL-Dienst“
  • Tabelle 257: TAB_KON_826 Fehlercodes „TLS-Verbindungsaufbau zum TSL-Dienst bei Prüfung der technischen Rolle“
  • Tabelle 258: TAB_KON_597 Operationen in EVT_MONITOR_OPERATIONS
  • Tabelle 259: TAB_KON_766 TUC_KON_032 „TSL aktualisieren“
  • Tabelle 260: TAB_KON_598 Fehlercodes TUC_KON_032 „TSL aktualisieren“
  • Tabelle 261: TAB_KON_618 TUC_KON_031 „BNetzA-VL aktualisieren“
  • Tabelle 262: TAB_KON_619 Fehlercodes TUC_KON_031 „BNetzA-VL aktualisieren“
  • Tabelle 263: TAB_KON_767 TUC_KON_040 „CRL aktualisieren“
  • Tabelle 264: TAB_KON_599 Fehlercodes TUC_KON_040 „CRL aktualisieren“
  • Tabelle 265: TAB_KON_768 TUC_KON_033 „Zertifikatsablauf prüfen“
  • Tabelle 266: TAB_KON_600 Fehlercodes TUC_KON_033 „Zertifikatsablauf prüfen“
  • Tabelle 267: TAB_KON_769 TUC_KON_037 „Zertifikat prüfen“
  • Tabelle 268: TAB_KON_601 Fehlercodes TUC_KON_037 „Zertifikat prüfen“
  • Tabelle 269: TAB_KON_818 TUC_KON_042 „CV-Zertifikat prüfen“ 
  • Tabelle 270: TAB_KON_819 Fehlercodes TUC_KON_042 „CV-Zertifikat prüfen“
  • Tabelle 271: TAB_KON_770 TUC_KON_034 „Zertifikatsinformationen extrahieren“
  • Tabelle 272: TAB_KON_602 Fehlercodes TUC_KON_034 „Zertifikatsinformationen extrahieren“
  • Tabelle 273: TAB_KON_771 Basisanwendung Zertifikatsdienst
  • Tabelle 274: TAB_KON_676 Operation CheckCertificateExpiration
  • Tabelle 275: TAB_KON_677 Ablauf CheckCertificateExpiration
  • Tabelle 276: TAB_KON_603 Fehlercodes „CheckCertificateExpiration“
  • Tabelle 277: TAB_KON_678 Operation ReadCardCertificate
  • Tabelle 278: TAB_KON_679 Ablauf ReadCardCertificate
  • Tabelle 279: TAB_KON_604 Fehlercodes „ReadCardCertificate“
  • Tabelle 280: TAB_KON_795 Operation VerifyCertificate
  • Tabelle 281: TAB_KON_797 Ablauf VerifyCertificate
  • Tabelle 282: TAB_KON_800 Fehlercodes „VerifyCertificate“
  • Tabelle 283: TAB_KON_772 TUC_KON_035 „Zertifikatsdienst initialisieren“
  • Tabelle 284: TAB_KON_605 Fehlercodes TUC_KON_035 „Zertifikatsdienst initialisieren“
  • Tabelle 285: TAB_KON_606 Konfiguration des Zertifikatsdienstes
  • Tabelle 286: TAB_KON_733 Einsehbare Konfigurationsparameter des Zertifikatsdienstes
  • Tabelle 287: TAB_KON_857 - Fehlercodes beim Import des Cross-Zertifikats für TI-Vertrauensanker ECC
  • Tabelle 288: TAB_KON_607 – TUC_KON_271 „Schreibe Protokolleintrag“
  • Tabelle 289: TAB_KON_608 Fehlercodes TUC_KON_271 „Schreibe Protokolleintrag“
  • Tabelle 290: TAB_KON_609 Konfigurationswerte des Protokollierungsdienstes (Administrator)
  • Tabelle 291: TAB_KON_610 – TUC_KON_272 „Initialisierung Protokollierungsdienst“
  • Tabelle 292: TAB_KON_611 Fehlercodes TUC_KON_272 „Initialisiere Protokollierungsdienst“
  • Tabelle 293: TAB_KON_773 – TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
  • Tabelle 294: TAB_KON_612 Fehlercodes TUC_KON_110 „Kartenbasierte TLS-Verbindung aufbauen“
  • Tabelle 295: TAB_KON_774 - TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
  • Tabelle 296: TAB_KON_613 Fehlercodes TUC_KON_111 „Kartenbasierte TLS-Verbindung abbauen“
  • Tabelle 297: TAB_KON_805 - TUC_KON_290 „LDAP-Verbindung aufbauen“
  • Tabelle 298: TAB_KON_815 – TUC_KON_291 „Verzeichnis abfragen“
  • Tabelle 299: TAB_KON_816 – TUC_KON_292 „LDAP-Verbindung trennen"
  • Tabelle 300: TAB_KON_817 – TUC_KON_293 „Verzeichnisabfrage abbrechen“
  • Tabelle 301: TAB_KON_780 – Signaturverfahren Externe Authentisierung
  • Tabelle 302: TAB_KON_839 Basisdienst Authentifizierungsdienst
  • Tabelle 303: TAB_KON_781 Operation ExternalAuthenticate
  • Tabelle 304: TAB_KON_782 Ablauf Operation ExternalAuthenticate
  • Tabelle 305: TAB_KON_783 Übersicht Fehler Operation ExternalAuthenticate
  • Tabelle 306: TAB_KON_784 Privater Schlüssel je Karte für ExternalAuthenticate
  • Tabelle 307: TAB_KON_680 Mapping der Netzwerksegmente
  • Tabelle 308: TAB_KON_681 Definition der vom Konnektor verwendeten VPN-Tunnel
  • Tabelle 309: TAB_KON_682 Definition der Konnektor IP-Adressen
  • Tabelle 310: TAB_KON_614 - TUC_KON_305 „LAN-Adapter initialisieren“
  • Tabelle 311: TAB_KON_615 Fehlercodes TUC_KON_305 „LAN-Adapter initialisieren“
  • Tabelle 312: TAB_KON_616 - TUC_KON_306 „WAN-Adapter initialisieren“
  • Tabelle 313: TAB_KON_617 Fehlercodes TUC_KON_306 „WAN-Adapter initialisieren“
  • Tabelle 314: TAB_KON_622 - TUC_KON_304 „Netzwerk-Routen einrichten“
  • Tabelle 315: TAB_KON_623 Fehlercodes TUC_KON_304 „Netzwerk-Routen einrichten“
  • Tabelle 316: TAB_KON_683 LAN-Adapter IP-Konfiguration
  • Tabelle 317: TAB_KON_684 LAN-Adapter Erweiterte Parameter
  • Tabelle 318: TAB_KON_685 WAN-Adapter IP-Konfiguration
  • Tabelle 319: TAB_KON_686 WAN-Adapter Erweiterte Parameter
  • Tabelle 320: TAB_KON_624 – „Konfigurationsparameter der Anbindung LAN/WAN“
  • Tabelle 321: TAB_KON_625 - Konfigurationsparameter Firewall-Schnittstelle
  • Tabelle 322: TAB_KON_626 „Liefere Netzwerkinformationen über DHCP“
  • Tabelle 323: TAB_KON_627 „Aktivierung des DHCP-Servers“
  • Tabelle 324: TAB_KON_628 „Basiskonfiguration des DHCP-Servers“
  • Tabelle 325: TAB_KON_629 „Client-Gruppenspezifische Konfigurationsoptionen des Konnektor-DHCP-Servers“
  • Tabelle 326: TAB_KON_630 - TUC_KON_343 „Initialisierung DHCP-Server“
  • Tabelle 327: TAB_KON_631 Fehlercodes TUC_KON_343 „Initialisierung DHCP-Server“
  • Tabelle 328: TAB_KON_632 – TUC_KON_341 „DHCP Informationen beziehen“
  • Tabelle 329: TAB_KON_633 Fehlercodes TUC_KON_341 „DHCP-Informationen beziehen“
  • Tabelle 330: TAB_KON_634 „Konfiguration des DHCP-Clients“
  • Tabelle 331: TAB_KON_635 – TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
  • Tabelle 332: TAB_KON_636 Fehlercodes TUC_KON_321 „Verbindung zu dem VPN-Konzentrator der TI aufbauen“
  • Tabelle 333: TAB_KON_637 – TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“
  • Tabelle 334: TAB_KON_638 Fehlercodes TUC_KON_322 „Verbindung zu dem VPN-Konzentrator der SIS aufbauen“
  • Tabelle 335: TAB_KON_639 – Konfigurationsparameter VPN-Client
  • Tabelle 336: TAB_KON_640 Zustandswerte für Konnektor NTP-Server
  • Tabelle 337: TAB_KON_776 TUC_KON_351 „Liefere Systemzeit“
  • Tabelle 338: TAB_KON_641 Fehlercodes TUC_KON_351 „Liefere Systemzeit“
  • Tabelle 339: TAB_KON_642 Operation sync_Time
  • Tabelle 340: TAB_KON_643 Konfiguration des Konnektor NTP-Servers
  • Tabelle 341: TAB_KON_730 Einsehbare Konfigurationsparameter des Konnektor NTP-Servers
  • Tabelle 342: TAB_KON_644 – TUC_KON_352 „Initialisierung Zeitdienst“
  • Tabelle 343: TAB_KON_645 Fehlercodes TUC_KON_352 „Initialisierung Zeitdienst“
  • Tabelle 344: TAB_KON_687 DNS-Forwards des DNS-Servers
  • Tabelle 345: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“
  • Tabelle 346: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“
  • Tabelle 347: TAB_KON_646 – TUC_KON_361 „DNS-Namen auflösen“
  • Tabelle 348: TAB_KON_647 Fehlercodes TUC_KON_361 „DNS Namen auflösen“
  • Tabelle 349: TAB_KON_648 – TUC_KON_362 „Liste der Dienste abrufen“
  • Tabelle 350: TAB_KON_649 Fehlercodes TUC_KON_362 „Liste der Dienste abrufen“
  • Tabelle 351: TAB_KON_650 - TUC_KON_363 „Dienstdetails abrufen“
  • Tabelle 352: TAB_KON_651 Fehlercodes TUC_KON_363 „Dienstdetails abrufen“
  • Tabelle 353: TAB_KON_652 Basisanwendung Namensdienst
  • Tabelle 354: TAB_KON_653 Operation GetIPAddress
  • Tabelle 355: TAB_KON_654 - Konfigurationsparameter Namensdienst
  • Tabelle 356: TAB_KON_731 Einsehbare Konfigurationsparameter Namensdienst
  • Tabelle 357: TAB_KON_655 Konfigurationen der Benutzerverwaltung (Super-Administrator)
  • Tabelle 358: TAB_KON_656 Konfigurationen der Benutzerverwaltung
  • Tabelle 359: TAB_KON_657 Konfigurationsparameter des Konnektornamens
  • Tabelle 360: TAB_KON_833 Bezeichner für persistente Konfigurationsdaten für Fachmodule
  • Tabelle 361: TAB_KON_658 Aktivieren/Deaktivieren von Leistungsumfängen
  • Tabelle 362: TAB_KON_659 Konnektor Standalone einsetzen
  • Tabelle 363: TAB_KON_661 Konfigurationsparameter der Konnektorfreischaltung
  • Tabelle 364: TAB_KON_732 Einsehbare Konfigurationsparameter der Konnektorfreischaltung
  • Tabelle 365: TAB_KON_662 Zustandswerte der Konnektorfreischaltung
  • Tabelle 366: TAB_KON_932 – TUC_KON_411 „Konnektor mit neuem NK-Zertifikat registrieren“
  • Tabelle 367: Tab_Kon_933 Fehlercodes TUC_KON_411 "Konnektor mit neuem NK-Zertifikat registrieren"
  • Tabelle 368: TAB_KON_851 Einschränkung der Rechte des Remote-Administrators (Denylist)
  • Tabelle 369: TAB_KON_663 Konfigurationen des Remote Managements
  • Tabelle 370: TAB_KON_664 – TUC_KON_280 „Konnektoraktualisierung durchführen“
  • Tabelle 371: TAB_KON_665 Fehlercodes TUC_KON_280 „Konnektoraktualisierung durchführen“
  • Tabelle 372: TAB_KON_666 – TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
  • Tabelle 373: TAB_KON_667 Fehlercodes TUC_KON_281 „Kartenterminalaktualisierung anstoßen“
  • Tabelle 374: TAB_KON_668 – TUC_KON_282 „UpdateInformationen beziehen“
  • Tabelle 375: TAB_KON_669 Fehlercodes TUC_KON_282 „UpdateInformationen beziehen“
  • Tabelle 376: TAB_KON_799 – TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
  • Tabelle 377: Tab_Kon_726 Fehlercodes TUC_KON_283 „Infrastruktur Konfiguration aktualisieren“
  • Tabelle 378: TAB_KON_833 – TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
  • Tabelle 379: TAB_KON_834 Fehlercodes TUC_KON_285 „UpdateInformationen für Fachmodul beziehen“
  • Tabelle 380: TAB_KON_835 – TUC_KON_286 „Paket für Fachmodul laden“
  • Tabelle 381: TAB_KON_836 Fehlercodes TUC_KON_286 „Paket für Fachmodul laden“
  • Tabelle 382: TAB_KON_864 – TUC_KON_284 „KSR-Client initialisieren“
  • Tabelle 383: TAB_KON_822 Fehlercodes TUC_KON_284 „KSR-Client initialisieren“
  • Tabelle 384: TAB_KON_670 Konfigurationsparameter der Software-Aktualisierung
  • Tabelle 385: TAB_KON_820 Einsehbare Konfigurationsparameter der Software-Aktualisierung
  • Tabelle 386: TAB_KON_671 Anforderungen Klima
  • Tabelle 387: TAB_KON_672 Anforderungen Vibration
  • Tabelle 388: TAB_KON_672 Anforderungen Vibration
  • Tabelle 389: TAB_KON_779-01 „Profilierung der Signaturformate“
  • Tabelle 390: TAB_KON_775 „Mindestanforderungen an Dimensionierung von Dokumenten und Nachrichten“
  • Tabelle 391: TAB_KON_889 „Unerlaubte Inhalte in Dokumenten und Nachrichten“
  • Tabelle 392: TAB_KON_777 Events Interne Mechanismen
  • Tabelle 393: TAB_KON_711 Architektur der TI-Plattform, Berechtigt Fachmodule
  • Tabelle 394: TAB_KON_712 Architektur der TI-Plattform, Berechtigt Clientsysteme
  • Tabelle 395: TAB_KON_713 Architektur der TI-Plattform, Berechtigt eHealth-KT
  • Tabelle 396: TAB_KON_714 Architektur der TI-Plattform, Berechtigt Administrator
  • Tabelle 397: Aufzähltypen
  • 5.5 Referenzierte Dokumente

    5.5.1 Dokumente der gematik

    Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

    [Quelle]
    Herausgeber: Titel
    [gemGlossar]
    gematik: Glossar
    [gemKPT_Arch_TIP]
    gematik: Konzept Architektur der TI-Plattform
    [gemKPT_Sich_Kon]
    gematik: Sicherheitskonzept Konnektor
    [gemKPT_Test]
    gematik: Testkonzept
    [gemSpec_COS]
    gematik: Spezifikation des Card Operating System (COS) – Elektrische Schnittstelle
    [gemSpec_Karten_Fach_TIP]
    gematik: Befüllvorschriften für die Plattformanteile der Karten der TI
    [gemSpec_eGK_ObjSys]
    gematik: Spezifikation der elektronischen Gesundheitskarte eGK-Objektsystem - für Karten der Generation 2
    [gemSpec_eGK_ObjSys_G2.1]
    gematik: Spezifikation der elektronischen Gesundheitskarte eGK-Objektsystem - für Karten der Generation 2.1
    [gemSpec_eGK_P1]
    gematik: Die Spezifikation der elektronische Gesundheitskarte; Teil 1 – Spezifikation der elektrischen Schnittstelle
    - für Karten der Generation 1+
    [gemSpec_eGK_P2]
    gematik: Die Spezifikation der elektronische Gesundheitskarte; Teil 2 – Grundlegende Applikationen
    - für Karten der Generation 1+
    [gemSpec_gSMC-K_ObjSys]
    gematik: Spezifikation der gSMC-K Objektsystem
    [gemSpec_gSMC-KT_ObjSys]
    gematik: Spezifikation gSMC-KT Objektsystem
    [gemSpec_HBA_ObjSys]
    gematik: Spezifikation HBA Objektsystem
    [gemSpec_Krypt]
    gematik: Übergreifende Spezifikation Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur
    [gemSpec_KSR]
    gematik: Spezifikation Konfigurationsdienst
    [gemSpec_KT]
    gematik: Spezifikation eHealth-Kartenterminal
    [gemSpec_Net]
    gematik: Spezifikation Netzwerk
    [gemSpec_OID]
    gematik: Spezifikation OID
    [gemSpec_OM]
    gematik: Übergreifende Spezifikation Operations und Maintenance
    [gemSpec_Perf]
    gematik: Performance und Mengengerüst TI-Plattform
    [gemSpec_PKI]
    gematik: Spezifikation PKI
    [gemSpec_SMC-B_ObjSys]
    gematik: Spezifikation SMC-B Objektsystem
    [gemSpec_VPN_ZugD]
    gematik: Spezifikation VPN-Zugangsdienst
    [gemSpec_VZD]
    gematik: Spezifikation Verzeichnisdienst
    gemGitHub_tslSig] https://github.com/gematik/examples-TelematikInterfaces/tree/master/tslService/detachedSignature 

    5.5.2 Weitere Dokumente

    [Quelle]
    Herausgeber (Erscheinungsdatum): Titel
    [7816–4]
    ISO/IEC 7816-4: 2005 (2nd edition) Identification cards — Integrated circuit cards - Part 4: Organization, security and commands for interchange
    [ALGCAT]
    SOG-IS Crypto Evaluation Scheme - Agreed Cryptographic Mechanisms, Version 1.2, Januar 2020.
    [Basic Profile1.2]
    Basic Profile Version 1.2
    http://www.ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html
    [Basic Profile2.0]
    Basic Profile Version 2.0
    http://www.ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html
    [BSI-TR-03111]
    Technical Guideline BSI TR-03111
    Elliptic Curve Cryptography, Version 2.10, Date: 2018-06-01
    https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03111/BSI-TR-03111_V-2-1_pdf.pdf?__blob=publicationFile&v=2 
    [BSI-TR03114]
    BSI (22.10.2007): Technische Richtlinie – Stapelsignatur mit dem Heilberufsausweis; Version 2.0
    https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ Publikationen/TechnischeRichtlinien/TR03114/BSI-TR-03114.pdf? __blob=publicationFile&v=1     
    [BSI TR-03120]
    BSI (23.10.2007): BSI - Technische Richtlinie – Sichere Kartenterminalidentität (Betriebskonzept); Version 1.0
    https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ Publikationen/TechnischeRichtlinien/TR03120/BSI-TR-03120.pdf? __blob=publicationFile&v=1    
    [CAdES]
    ETSI: Electronic Signature Formats, Electronic Signatures and Infrastructures (ESI) – Technical Specification, ETSI TS 101 733 V2.2.1, via http://www.etsi.org
    [Canon XML1.1]
    Canonical XML Version 1.1
    http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/
    [CDA]
    ISO/HL7 27932:2009 Data Exchange Standards -- HL7 Clinical Document Architecture, Release 2
    [CDA-Sig]
    Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture – R2, Elektronische Signatur von Arztbriefen,  Ärztekammern in NRW im Auftrag der Bundesärztekammer, Version 1.6 vom 19.04.2010
    [COMMON_PKI]
    Common PKI Specifications for Interoperable Applications
    Version 2.0, 20 January 2009
    http://www.t7ev.org/themen/entwickler/common-pki-v20-spezifikation.html
    ISIS-MTT Core Specification, 2004, Version 1.1
    https://www.teletrust.de/fileadmin/files/ ISIS-MTT_Profile_SigGOptions_v1.1.pdf  
    [CMS]
    Cryptographic Message Syntax (CMS), September 2009
    https://datatracker.ietf.org/doc/html/rfc5652 
    [DIN 66003]
    DIN 66003:1999
    Informationsverarbeitung; 7-Bit-Code
    [HPC-P1]
    Spezifikation des elektronischen Heilberufsausweises
    Version 2.3.2, 05.08.2009, Teil I: Kommandos, Algorithmen und Funktionen der COS Plattform
    [HPC-P2]
    Spezifikation des elektronischen Heilberufsausweises
    Version 2.3.2, 05.08.2009, Teil II: HPC - Anwendungen und Funktionen
    [HPC-P3]
    Spezifikation des elektronischen Heilberufsausweises
    Version 2.3.2, 05.08.2009, Teil III: SMC - Anwendungen und Funktionen
    [HüKo06]
    BSI (2006):
    Hühnlein, Detlef/Korte, Ulrike:Grundlagen der elektronischen Signatur
    [IEEE 802.3]
    Technical Committee Computer Communications of the IEEE Computer Society, USA (1985):
    IEEE standards for local area networks: carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications
    ISBN: 0-7381-4253-0
    [ISO 8601]
    International Organization for Standardization (2006-09): Data elements and interchange formats -- Information interchange -- Representation of dates and times
    [KVK]
    Spitzenverbände der Krankenkassen, Kassenärztliche Bundesvereinigung und Kassenzahnärztlichen Bundesvereinigung (gültig ab 25. November 2009):
    Technische Spezifikation der Versichertenkarte Version: 2.08
    [MIME]
    RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049
    [NTPv4]
    Internet Engineering Task Force (IETF) (06/2010): Network Time Protocol Version 4: Protocol and Algorithms Specification
    https://datatracker.ietf.org/doc/html/rfc5905 
    [OASIS-
    AdES]
    OASIS: Advanced Electronic Signature Profiles of the OASIS Digital Signature Service Version 1.0, OASIS Standard,
    http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES-spec-v1.0-os.pdf
    [OASIS-DSS]
    OASIS: Digital Signature Service Core Protocols, Elements, and Bindings, Version 1.0, OASIS Standard, via
    http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf
    [OASIS-SP]
    OASIS: Signature Policy Profile of the OASIS Digital Signature Services Version 1.0, Committee Draft 01, 18 May 2009, http://docs.oasis-open.org/dss-x/profiles/sigpolicy/oasis-dssx-1.0-profiles-sigpolicy-cd01.pdf
    [OASIS-VR]
    OASIS: Profile for comprehensive multi-signature verification reports for OASIS Digital Signature Services Version 1.0, Committee Specification 01, 12 November 2010, http://docs.oasis-open.org/dss-x/profiles/verificationreport/oasis-dssx-1.0-profiles-vr-cs01.pdf
    [PAdES-1]
    European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 1: PAdES Overview – a framework document for PAdES,
    ETSI TS 102 778-1 V1.1.1, Technical Specification, 2009
    [PAdES-3]
    European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced – PAdES-BES and PAdES-EPES Profiles, ETSI TS 102 778-3 V1.1.2, Technical Specification, 2009
    [PAdES-4]
    European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 4: PAdES Long Term – PAdES-LTV Profile, ETSI TS 102 778-4 V1.1.2, Technical Specification, 2009
    [ISO 19005]
    ISO 19005 – Document management – Electronic document file format for long-term preservation
    [PDF/A-2]
    ISO 19005-2:2011 – Document management – Electronic document file format for long-term preservation – Part 2: Use of ISO 32000-1 (PDF/A-2)
    [PP_NK]
    Common  Criteria  Schutzprofil  (Protection  Profile)
    Schutzprofil 1: Anforderungen an den Netzkonnektor
    BSI-CC-PP-0097
    [PP_KON]
    Common  Criteria  Schutzprofil  (Protection  Profile)
    Schutzprofil 2: Anforderungen an den Konnektor:
    BSI-CC-PP-0098
    [RFC792]
    IETF (September 1981) INTERNET CONTROL MESSAGE PROTOCOL
    https://datatracker.ietf.org/doc/html/rfc792 
    [RFC1034]
    RFC 1034 (November 1987): Domain Names – Concepts and Facilities
    https://datatracker.ietf.org/doc/html/rfc1034 
    [RFC1122]
    RFC 1122 (Oktober 1989): Requirements for Internet Hosts -- Communication Layers
    https://datatracker.ietf.org/doc/html/rfc1122 
    [RFC1812]
    F. Baker (ed.): Requirements for IP Version 4 Routers, IETF RFC 1812
    https://datatracker.ietf.org/doc/html/rfc1812 
    [RFC1918]
    RFC1918 (Februar 1996): Address Allocation for Private Internets
    https://datatracker.ietf.org/doc/html/rfc1918 
    [RFC2119]
    RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels S. Bradner https://datatracker.ietf.org/doc/html/rfc2119 
    [RFC2131]
    Network Working Group (03/1997): Dynamic Host Configuration Protocol
    https://datatracker.ietf.org/doc/html/rfc2131 
    [RFC2132]
    Network Working Group (03/1997): DHCP Options and BOOTP Vendor Extensions
    https://datatracker.ietf.org/doc/html/rfc2132 
    [RFC2616]
    Network Working Group (06/1999): Hypertext Transfer Protocol -- HTTP/1.1
    https://datatracker.ietf.org/doc/html/rfc2616 

    [RFC2617]
    Network Working Group (06/1999): HTTP Authentication: Basic and Digest Access Authentication
    https://datatracker.ietf.org/doc/html/rfc2617 
    [RFC2644]
    D. Senie: Changing the Default for Directed Broadcasts in Routers, IETF RFC 2644,
    https://datatracker.ietf.org/doc/html/rfc2644 

    [RFC2663]
    P. Srisuresh, M. Holdrege: IP Network Address Translator (NAT) Terminology and Considerations, IETF RFC 2663, https://datatracker.ietf.org/doc/html/rfc2663 
    [RFC2818]
    Network Working Group (05/2000): HTTP Over TLS
    https://datatracker.ietf.org/doc/html/rfc2818 
    [RFC3022]
    RFC 3022 (Januar 2001): Traditional IP Network Address Translator (Traditional NAT)
    https://datatracker.ietf.org/doc/html/rfc3022 
    [RFC3275]
    D. Eastlage, J. Reagle, D. Solo: (Extensible Markup Language) XMLSignature Syntax and Processing, IETF RFC 3275, https://datatracker.ietf.org/doc/html/rfc3275 
    [RFC3279]
    W, Polk, R. Hously, L. Bassham: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF RFC 3279, https://datatracker.ietf.org/doc/html/rfc3279 
    [RFC3447]
    B. Kaliski:_PKCS #1: RSA Encryption, Version 2.1
    https://datatracker.ietf.org/doc/html/rfc3447 

    [RFC3629]
    Network Working Group (11/2003): UTF-8, a transformation format of ISO 10646
    https://datatracker.ietf.org/doc/html/rfc3629 
    [RFC3927]
    Network Working Group (05/2005): Dynamic Configuration of IPv4 Link-Local Addresses
    https://datatracker.ietf.org/doc/html/rfc3927 
    [RFC3986]
    Network Working Group (01/2005): Uniform Resource Identifier (URI): Generic Syntax
    [RFC4122]
    RFC 4122 (July 2005): A Universelly Unique Identifier UUID URN Namspace
    https://datatracker.ietf.org/doc/html/rfc4122 
    [RFC4511] RFC 4511 (June 2006): Lightweight Directory Access Protocol (LDAP): The Protocol
    https://datatracker.ietf.org/doc/html/rfc4511 
    [RFC4632]
    Network Working Group (08/2006): Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan
    https://datatracker.ietf.org/doc/html/rfc4632 
    [RFC5246]
    RFC 5246 (August 2008): The Transport Layer Security (TLS) Protocol Version 1.2;
    https://datatracker.ietf.org/doc/html/rfc5246 
    [RFC5652]
    R. Housley: Cryptographic Message Syntax (CMS), RFC 5652 (September 2009)
    https://datatracker.ietf.org/doc/html/rfc5652 
    [RFC 6598]
    RFC 6598 (April 2012): IANA-Reserved IPv4 Prefix for Shared Address Space
    https://datatracker.ietf.org/doc/html/rfc6598 
    [RFC6931]
    RFC 6931 (April 2013): Additional XML Security Uniform Resource Identifiers (URIs)
    https://datatracker.ietf.org/doc/html/rfc6931 
    [RFC7159]
    RFC 7159 (March 2014): The JavaScript Object Notation (JSON) Data Interchange Format
    https://datatracker.ietf.org/doc/html/rfc7159 
    [S/MIME]
    RFC 5751  (Januar  2010): Secure/Multipurpose Internet Mail Extensions  (S/MIME), Version 3.2, Message Specification
    https://datatracker.ietf.org/doc/html/rfc5751 
    [SOAP1.1]
    Simple Object Access Protocol (SOAP) 1.1
    W3C Note (08 May 2000)
    https://www.w3.org/TR/2000/NOTE-SOAP-20000508/ 
    [SOAP1.2]
    SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)
    W3C Recommendation (27 April 2007)
    http://www.w3.org/TR/2007/REC-soap12-part1-20070427/
    [SICCT]
    TeleTrusT (17.12.2010): SICCT Secure Interoperable ChipCard Terminal,
    Version 1.21
    https://www.teletrust.de/fileadmin/docs/projekte/sicct/SICCT-Spezifikation-1.21.pdf 
    [TIFF6]
    TIFF Revision 6.0 (Final, June 3, 1992)
    https://www.adobe.io/open/standards/TIFF/_jcr_content/ contentbody/download/file.res/TIFF6.pdf.html 
    [WSDL1.1]
    W3C Note (15.03.2001):
    Web Services Description Language (WSDL) 1.1
    http://www.w3.org/TR/wsdl
    [XAdES]
    European Telecommunications Standards Institute (ETSI): Technical Specication XML Advanced Electronic Signatures (XAdES). ETSI Technical Specication TS 101 903, Version 1.4.2, 2010
    [XMLDSig]
    W3C Recommendation (06.2008):
    XML-Signature Syntax and Processing
    http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/
    [XMLEnc]
    XML Encryption Syntax and Processing
    W3C Recommendation 11 April 2013
    http://www.w3.org/TR/xmlenc-core1/
    [XPATH]
    W3C Recommendation (14 December 2010)
    XML Path Language (XPath) 2.0 (Second Edition)
    http://www.w3.org/TR/2010/REC-xpath20-20101214/
    [XSLT]
    W3C Recommendation (23 January 2007)
    XSL Transformations (XSLT) Version 2.0
    http://www.w3.org/TR/2007/REC-xslt20-20070123/
    [XAdES Baseline
    Profile]
    European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); XAdES Baseline Profile; ETSI Technical Specification TS 103 171, Version 2.1.1, 2012-03
    [CAdES Baseline
    Profile]
    European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); CAdES Baseline Profile; ETSI Technical Specification TS 103 173, Version 2.1.1, 2013-04
    [PAdES Baseline
    Profile]
    European Telecommunications Standards Institute (ETSI): Electronic Signatures and Infrastructure (ESI); PAdES Baseline Profile; ETSI Technical Specification TS 103 172, Version 2.2.2, (2013-04)
    [XSL]
    W3C Recommendation (05.12.2006):
    Extensible Stylesheet language (XSL) Version1.1
    http://www.w3.org/TR/2006/REC-xsl11-20061205/
    [MTOM]
    SOAP Message Transmission Optimization Mechanism
    W3C Recommendation 25 January 2005
    http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/
    [MTOM-SOAP1.1]
    W3C Member Submission 05 April 2006
    SOAP 1.1 Binding for MTOM 1.0
    https://www.w3.org/Submission/soap11mtom10/
    [WS-MTOM Policy]
    W3C Member Submission 18 November 2007
    MTOM Serialization Policy Assertion 1.1
    [COS-G2]
    Common Criteria Protection Profile, Card Operating System Generation 2, (PP COS G2), BSI-CC-PP-0082-V2

    6 Anhang B – Profilierung der Signatur- und Verschlüsselungsformate (normativ)

    6.1 Profilierung der Verschlüsselungsformate

    6.2 Profilierung der Signaturformate

    Tabelle 389: TAB_KON_779-01 „Profilierung der Signaturformate“

    Aspekt
    (QES/nonQES)
    Festlegung
    (XML-Signatur/CMS-Signatur/PDF-Signatur)
    Zertifikatsreferenz
    (QES und nonQES)
    XML-Signatur
    Bei der Signaturerstellung ist das XML-Element SigningCertificate gemäß den Vorgaben aus XAdES Kapitel 7.2.2 „The SigningCertificate element“ anzulegen.
    Bei der Signaturprüfung ist es gemäß XAdES Kapitel G.2.2.5 „Verification technical rules” [XAdES] zu prüfen. Grundsätzlich sind auch Signaturen zu prüfen, die keine Zertifikatsreferenz enthalten. Das Prüfergebnis muss dann widerspiegeln, dass diese Sicherheitsfunktion nicht enthalten war.
    CMS-Signatur
    Bei der Signaturerstellung ist das Attribut signing certificate reference gemäß CAdES Kapitel 5.7.3 „Signing Certificate Reference Attributes“ [CAdES] anzulegen.
    Bei der Signaturprüfung ist es gemäß CAdES Kapitel 5.6.3 „Message signature verification process“ [CAdES] zu prüfen.
    Grundsätzlich sind auch Signaturen zu prüfen, die keine Zertifikatsreferenz enthalten. Das Prüfergebnis muss dann widerspiegeln, dass diese Sicherheitsfunktion nicht enthalten war.
    PDF-Signatur
    Bei der Signaturerstellung ist das Attribut signing certificate reference gemäß den Vorgaben aus [PAdES-3] Kapitel 4.4.3 „Signing Certificate Reference Attribute“ anzulegen.
    Bei der Signaturprüfung ist es gemäß [PAdES-3]Kapitel 4.6.1 „Signing Certificate Reference Validation“ zu prüfen. Grundsätzlich sind auch Signaturen zu prüfen, die keine Zertifikatsreferenz enthalten. Das Prüfergebnis muss dann widerspiegeln, dass diese Sicherheitsfunktion nicht enthalten war.
    Signaturablage PDF-Signatur
    Sie Signatur wird als Incremental Update gemäß [PDF/A-2] Kapitel 7.5.6 an das Dokument angefügt.
    Parallelsignatur
    (QES und nonQES)
    XML-Signatur
    Parallele Signaturen werden durch je ein ds:signature-Element pro Signatur abgebildet. Für die Signaturvariante „enveloping“ werden parallele Signaturen nicht angeboten.
    CMS-Signatur:
    Parallele Signaturen werden durch je einen SignerInfo-Container pro Signatur realisiert.
    PDF-Signatur:
    Parallele Signaturen werden nicht angeboten.
    Dokumentexkludierende Gegensignatur
    (QES und nonQES)
    XML-Signatur
    Die Implementierung erfolgt mittels Countersignature gemäß [XAdES], Kapitel 7.2.4. Jede vorhandene Parallel-Signatur wird gegensigniert.
    CMS-Signatur:
    Die Implementierung erfolgt mittels der Countersignature gemäß CMS-Spezifikation [RFC5652]. Jede vorhandene Parallel-Signatur wird gegensigniert.
    PDF-Signatur:
    Dokumentexkludierende Gegensignaturen werden nicht angeboten.
    Referenzierung
    (QES und nonQES)
    XML-Signatur
    Bei der Signaturerzeugung verwendet der Konnektor in der Signatur nur ID-basierte Referenzen. Bei der Signaturprüfung reagiert der Konnektor bei Abweichungen hiervon mit Fehler 4208.
    XML-Signatur / CMS-Signatur
    Bei XML-Dokumenten und XML-Signaturen kann die Referenzierung von Objekten auf zwei Arten erfolgen: 
    – Ist kein XML-Schema vorhanden, so werden die Werte des ID-Attributs des referenzierten Elements verwendet.
    – Wird ein XML-Schema übergeben, so muss dieses die ID-Attribute zur Referenzierung festlegen.
    Bei Abweichungen reagiert der Konnektor mit Fehlercode 4115.
    Anzahl unterstützter Signaturen
    (QES und nonQES)
    XML-Signatur / CMS-Signatur / PDF-Signatur
    Es müssen mindestens 20 Signaturen pro Dokument unterstützt werden. Sind mehr als die unterstützte Anzahl von Signaturen in einem Dokument enthalten, wird die Operation mit Fehler 4280 abgebrochen.

    6.3 Profilierung VerificationReport

    Anforderung eines ausführlichen Prüfberichts

    Folgende Aufrufparameter müssen unterstützt werden:

    <ReturnVerificationReport

    xmlns="urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:schema#" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

    xsi:schemaLocation="urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:schema#

    oasis-dssx-1.0-profiles-vr-cd1.xsd">

    <IncludeVerifier>false</IncludeVerifier>

    <IncludeCertificateValues>true</IncludeCertificateValues>

    <IncludeRevocationValues>true</IncludeRevocationValues>

    <ExpandBinaryValues>false</ExpandBinaryValues>  

    <ReportDetailLevel>

    urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:reportdetail:allDetails

    </ReportDetailLevel>

    </ReturnVerificationReport>


    Verwendung des erzeugten VerificationReport

    Für die folgenden Inhalte müssen die angegebenen Strukturen benutzt werden. Im Standard angegebene Pflichtfelder von erzeugten Strukturen müssen ggf. zusätzlich gefüllt werden:

    1. Prüfzeitpunkt (Systemzeit des Konnektors zum Zeitpunkt der Prüfung)

    /VerificationReport/

        dss:VerificationTimeInfo/    

            dss:VerificationTime

    1. Signaturzeitpunkt(Ermittelter_Signaturzeitpunkt_Eingebettet)

    /VerificationReport/

        IndividualReport/

            SignedObjectIdentifier/

                SignedProperties/

                    SignedSignatureProperties/

                        XAdES:SigningTime

    Die Signierzeit SigningTime ist nicht nur für XAdES-Signaturen, sondern allgemein für Signaturen gemäß AdES-Baseline-Profilierung, also auch für CAdES und PAdES zu füllen.

    1. Angenommener Signaturzeitpunkt gemäß TIP1-A_5540-* (QES) und TIP1-A_5545 (nonQES)

    /VerificationReport/
        IndividualReport/
               Details/
                dss:VerificationTimeInfo/
                    dss:VerificationTime

    1. der binäre Wert der Signatur

    /VerificationReport/

        IndividualReport/

            SignedObjectIdentifier/

                SignatureValue

    1. Kurztext

    Der signierte Kurztext wird in folgendem XML-Element zurückgegeben:

    /VerificationReport/

          IndividualReport/

                 SignedObjectIdentifier/

                       SignedProperties/

                            Other/
                                SIG:ShortText

    Die ungültigen Zeichen müssen aus dem ShortText entfern werden und der ShortText wird gekürzt, wenn er nicht den Längenvorgaben des Schemas entspricht. 

    1. Das folgende Element mit den Werten true/false gibt an, ob eine Zertifikatsreferenz gemäß Anhang B2 vorhanden ist (true) oder nicht (false):

    /VerificationReport/

          IndividualReport/

                 SignedObjectIdentifier/

                       SignedProperties/

                            Other/
                                    SIG:ReferenceToSignerCertificate

    1. Sämtliche signierte Attribute, deren Rückgabe nicht explizit über andere Elemente geregelt ist, werden als direkt anzeigbare Key/Value-Paare zurückgeben. Dabei sind sowohl Key und Value bereits für die Anzeige formatiert. Der Key wird in einer Zeile dargestellt. Der Value wird in mehreren Zeilen dargestellt, wobei ein Zeilenumbruch durch 'CARRIAGE RETURN (CR)' 'LINE FEED (LF)' erzeugt wird und keine weiteren Steuerzeichen erlaubt sind.

    /VerificationReport/

          IndividualReport/

                 SignedObjectIdentifier/

                       SignedProperties/

                            Other/
                                    SIG:DisplayableAttributes

    1. das Ergebnis der Signaturprüfung

    /VerificationReport/

        IndividualReport/

            Result

    1. handelt es sich bei der Signatur um eine Gegensignatur wird diese als solche markiert

      /DetailedSignatureReport/

    Properties/

    UnsignedProperties/

        Other/

            SIG:CounterSignatureMarker    


    und mit


    /DetailedSignatureReport/

    Properties/

    UnsignedProperties/

        Other/

            SIG:CounterSignatureMarker/

    SignatureValueReference/

            @IdRef
            

    auf jede (eine oder mehrere) gegensignierte Signaturen verwiesen.  Dabei zeigt  IdRef auf den jeweiligen gegensignierten Signaturwert

    /VerificationReport/

        IndividualReport/

            SignedObjectIdentifier/

                ds:SignatureValue/

                    @Id

    1. das Ergebnis der Zertifikatsprüfung,

    /VerificationReport/

        IndividualReport/

            Details/

                DetailedSignatureReport/

                    CertificatePathValidity/

                        PathValiditySummary/

                            ResultMajor

    1. Inhalt des Zertifikates, auf dem beruhend signiert wurde 

    /VerificationReport/

        IndividualReport/

            Details/

                DetailedSignatureReport/

                    CertificatePathValidity/

                        PathValidityDetail/

                            CertificateValidity/

                                CertificateValue

    1. den Signaturalgorithmus der Dokumentensignatur (URI, angelehnt an den Wertebereich des Feldes ds:SignatureMethod),

    /VerificationReport/

        IndividualReport/

            Details/

                DetailedSignatureReport/

                    SignatureOK/    

                        SignatureAlgorithm    

                            

    1. aussagekräftiger Hinweis zum verminderten Beweiswert hinsichtlich Authentizität und Integrität der Signatur, wenn einer der bei der Signaturprüfung identifizierten und unterstützten Algorithmen zum Zeitpunkt der Signaturprüfung nicht mehr laut Algorithmenkatalog [ALGCAT] als geeignet eingestuft wird. Auszuwerten sind die Festlegungen des ALGCAT sowohl bezogen auf die Vergangenheit als auch auf die Zukunft.

    Für alle geprüften Zertifikate:

    ../

    vr:CertificateValidity/

            vr:SignatureOK/

                vr:SignatureAlgorithm/

                    vr:Suitability/

    ./ResultMajor= urn:oasis:names:tc:dss:1.0:detail:invalid

    ./ResultMessage=“Algorithmen seit <Jahr> als unsicher eingestuft“

    1. PathValidity bis zur TrustAnchor-TSL

    //CertificateValidity/ChainingOK/ResultMajor (ab dem zweiten Zertifikat in der Kette)

    //CertificateValidity/CertificateStatus/CertStatusOK/ResultMajor

    //CertificateValidity/CertificateValue

    Für das Feld TrustAnchor ist

    “urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:trustanchor:certDataBase”

    zu verwenden.

    1. Prüfergebnis des Gültigkeitszeitraums

    /VerificationReport/

        IndividualReport/

            Details/

                DetailedSignatureReport/

                    CertificatePathValidity/

                        PathValidityDetail/

                            CertificateValidity/

                                ValidityPeriodOK/

                                    ResultMajor

    1. Prüfung der Extensions

    /VerificationReport/

        IndividualReport/

            Details/

                DetailedSignatureReport/

                    CertificatePathValidity/

                        PathValidityDetail/

                            CertificateValidity/

                                ExtensionsOK/

                                    ResultMajor

    1. Zeitstempel und Herkunft der OCSP-Antwort für das Signaturzertifikat

    /VerificationReport/

        IndividualReport/

            Details/

                DetailedSignatureReport/

                    CertificatePathValidity/

                            PathValidityDetail/

                                CertificateValidity/

                                    CertificateStatus/

                                        RevocationEvidence/

                                            OCSPValidity/

                                                OCSPIdentifier/

                ./XAdES:ResponderID/XAdES:ByName

                ./XAdES:ProducedAt

    1. OCSP Antwort für das Signaturzertifikats

    /VerificationReport/

        IndividualReport/

            Details/

                /vr:DetailedSignatureReport/

                    vr:CertificatePathValidity/

                        vr:PathValidityDetail/

                            vr:CertificateValidity/

                                vr:CertificateStatus/

                                    vr:RevocationEvidence/

                                        vr:OCSPValidity/

                                            vr:OCSPValue

    Sonderfälle:

    Dokument mit parallelen Signaturen

        Für jede Signatur wird ein IndividualReport erzeugt.

    Dokument mit Signatur und Gegensignatur

        Für jede Signatur wird ein IndividualReport erzeugt.    

    6.4 Profilierung der Dokumentenformate und Nachrichten

    Tabelle 390: TAB_KON_775 „Mindestanforderungen an Dimensionierung von Dokumenten und Nachrichten“

    Dokument / Nachricht Mindestanforderung
    XML-Dokument Hierarchietiefe des Dokumentenbaums: 30 Ebenen 
    Anzahl von XML-Elementen im Dokument: 30.000
    Anzahl von XML-Attributen je XML-Element: 20
    Anzahl von direkten Kindern eines XML-Elements: 50
    Länge von XML-Bezeichnern (z. B. Elementnamen, Attributnamen, Namespace-Präfixes, usw.): 200
    Gesamtanzahl von Transformationen im Dokument: 64
    Anzahl von Transformationen pro Reference-Element: 10
    Element-Größe pro Einzelknoten im Base64-codierten Dokument: 30 MB

    Tabelle 391: TAB_KON_889 „Unerlaubte Inhalte in Dokumenten und Nachrichten“

    Dokument / Nachricht Unerlaubte Inhalte
    XML-Dokument Es dürfen keine ENTITY-Deklarationen im XML-Dokument vorkommen.
    Zu verifizierende XML-Dokumente dürfen im <Transforms>-Teil ihrer Referenzen weder XPath-Ausdrücke noch XSL-Transformationen enthalten.
    Bei Referenzen (ReferenceType) darf das optionale URI-Attribut keine "xpointer()"-Ausdrücke enthalten.
    XInclude-Mechanismen dürfen nicht verwendet werden. Elemente aus dem Namensraum http://www.w3.org/2001/XInclude dürfen in XML-Dokumenten nicht enthalten sein.

    7 Anhang F – Übersicht Events

    Tabelle 392: TAB_KON_777 Events Interne Mechanismen

    Topic Ebene1
    /Topic Ebene2
    /Topic Ebene3
    Typ
    Schw
    ere
    Pr
    ot
    An
    Cli
    en
    ts
    Parameter
    Bedeutung
    Auslöser
    (TUC/Op)
    Interne Mechanismen
    BOOTUP
    /BOOTUP_COMPLETE
    Op
    Info
    x
    x

    Änderung des Betriebszustandes

    OPERATIONAL_STATE
    /EC_CardTerminal_Software_Out_Of_Date
    ($ctId)
    Op
    Info
    x
    x
    Value=true/
    false;
    CtID=$ctId;
    Bedeutung=
    $EC.description
    Änderung des Betriebszustandes
    durch Änderung im
    Fehlerzustand
    (Änderung im
    Value).

    OPERATIONAL_STATE
    /EC_CardTerminal_gSMC-KT_Certificate_Expires_Soon($ctId)
    Op Info x x Value=true/
    false;
    CtID=$ctId;
    Bedeutung=
    $EC.description
    Änderung des Betriebszustandes
    durch Änderung im
    Fehlerzustand
    (Änderung im
    Value).
    TUC_KON_050
    OPERATIONAL_STATE
    /EC_Connector_Software_Out_Of_Date
    Op
    Info
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_FW_Not_Valid_Status_Blocked
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Time_Sync_Not_Successful
    Op
    Info
    x
    x
    Value=true/
    false;
    LastSyncAttempt=
    $lastSyncAttempt
    Timestamp;
    LastSyncSuccess=
    $lastSyncSuccess
    Timestamp;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_TSL_Update_Not_Successful
    Op
    Info
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description;
    LastUpdateTSL=
    $lastUpdate
    TSLTimestamp
    "

    OPERATIONAL_STATE
    /EC_TSL_Expiring
    Sec
    Info
    x
    x
    Value=true/
    false;
    NextUpdateTSL=
    $NextUpdate-
    Element der TSL;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_TSL_Trust_Anchor_Expiring
    Sec
    Info
    x
    x
    Value=true/
    false;
    ExpiringDate
    TrustAnchor=
    Ablaufdatum
    der Vertrauens
    ankergültigkeit;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_LOG_OVERFLOW
    Op
    Warning
    x
    x
    Value=true/
    false;
    Protokoll=$Protokoll;
    Bedeutung=
    $EC.description
    "
    TUC_KON_271
    OPERATIONAL_STATE
    /EC_CRL_Expiring
    Sec
    Warning
    x
    x
    Value=true/
    false;
    NextUpdateTSL=
    $NextUpdate-
    Element der TSL;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Time_Sync_Pending_Warning
    Sec
    Warning
    x
    x
    Value=true/
    false;
    LastSyncSuccess=
    $lastSyncSuccess
    Timestamp;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_TSL_Out_Of_Date_Within_Grace_Period
    Sec
    Warning
    x
    x
    Value=true/
    false;
    NextUpdateTSL=
    $NextUpdate-
    Element der TSL;
    GracePeriodTSL=
    CERT_TSL_
    DEFAULT_GRACE_
    PERIOD_DAYS;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_CardTerminal_Not_Available($ctId)
    Op
    Error
    x
    x
    Value=true/
    false;
    CtID=$ctId;
    Bedeutung
    =$EC.description
    "

    OPERATIONAL_STATE
    /EC_No_VPN_TI_Connection
    Op
    Error
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_No_VPN_SIS_Connection
    Op
    Error
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_No_Online_Connection
    Op
    Error
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_IP_Adresses_Not_Available
    Sec
    Error
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_CRL_Out_Of_Date
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    NextUpdateCRL=
    $NextUpdate der CRL;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Firewall_Not_Reliable
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Random_Generator_Not_Reliable
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Secure_KeyStore_Not_Available
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Security_Log_Not_Writable
    Op
    Fatal
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Software_Integrity_Check_Failed
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Time_Difference_Intolerable
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description;
    NtpTimedifference=
    Zeitabweichung;
    NtpMaxAllowedTime
    difference=
    NTP_MAX_TIMEDIF
    FERENCE;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_Time_Sync_Pending_Critical
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    LastSyncSuccess=
    $lastSyncSuccess
    Timestamp;
    NtpGracePeriod=
    NTP_GRACE_PERIOD;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_TSL_Trust_Anchor_Out_Of_Date
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    ExpiringDate
    TrustAnchor=
    Ablaufdatum der
    Vertrauensanker
    gültigkeit;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_TSL_Out_Of_Date_Beyond_Grace_Period
    Sec
    Fatal
    x
    x
    Value=true/
    false;
    Next
    UpdateTSL=
    $NextUpdate-Element der TSL;
    GracePeriodTSL=
    CERT_TSL_ DEFAULT_
    GRACE_PERIOD_DAYS;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_CRYPTOPERATION_ALARM
    Sec
    Warning
    x
    x
    Value=true/
    false;
    Operation=
    $Operationsname;
    Count=$Summenwert;
    Arbeitsplatz
    =$<Liste operations-aufrufenden
    workplace IDs>;
    Meldung=’
    Auffällige
    Häufung von
    Operationsaufrufen in den letzten
    10 Minuten’
    "

    OPERATIONAL_STATE
    /EC_OTHER_ERROR_STATE($no)
    $Type
    $Seve
    rity
    x
    x
    Value=true/
    false;
    Bedeutung=
    $EC.description
    "

    OPERATIONAL_STATE
    /EC_BNetzA_VL_Update_Not_Successful
    Op
    Info
    x
    x
    Value=true/
    false;
    LastUpdate
    BNetzAVL=
    $lastUpdateBNetzAVL
    Timestamp;
    Bedeutung=
    $EC.description;
    "

    OPERATIONAL_STATE
    /EC_BNetzA_VL_not_valid
    Sec
    Warning
    x
    x
    Value=true/
    false;
    NextUpdate
    BNetzAVL=
    $NextUpdate-Element der BNetzA-VL;
    Bedeutung=
    $EC.description;
    "

    OPERATIONAL_STATE
    /EC_FW_Update_Available
    Op Info x x Bedeutung=
    $EC.description
    I_KSRS_Download::list_
    Updates
    liefert mindestens eine
    UpdateInformation mit einer UpdateInformation/Firmware/
    FWVersion > aktuelle Version
    der Konnektor- oder Kartenterminalsoftware
    OPERATIONAL_STATE/EC_NK_Certificate_Expiring Sec Warning x x Iccsn=$Iccsn;
    Serial=$Serialnumber;
    Bedeutung=
    $EC.description
    Das C.NK.VPN-Zertifikat läuft bald ab. 
    Systemzeit t > (Ablaufdatum von C.NK.VPN – 180 Tage)
    OPERATIONAL_STATE
    /EC_NK_Certificate_Expired
    Sec Fatal x x Iccsn=$Iccsn;
    Serial=$Serialnumber;
    Bedeutung=
    $EC.description
    Das C.NK.VPN-Zertifikat ist abgelaufen.
    Systemzeit t > Ablaufdatum von C.NK.VPN
    OPERATIONAL_STATE
    /EC_TLS_Client_Certificate_Security
    Sec Info x x Bedeutung=
    $EC.description
    Das für die Authentifizierung gegenüber dem Clientsystem konfigurierte Zertifikat hat ein Sicherheitsniveau von weniger als 120bit. Zu verwenden ist ein RSA -Zertifikat mit mindestens 3000 bit Schlüssellänge oder ein ECC Zertifikat.
    Zugriffsberechtigungsdienst
    Dokumentvalidierungsdienst
    Dienstverzeichnisdienst








    Kartenterminaldienst
    CT
    /ERROR
    $Error
    Type
    $Seve
    rity
    x
    x
    CtID=$CT.ID;
    Name=$CT.HOSTNAME;
    Error=$Fehlercode;
    Bedeutung=
    $Fehlertext
    Bei der Kommunikation mitdem KT ist ein Fehler aufgetreten
    TUC_KON_051
    TUC_KON_053
    CT
    /CONNECTED
    Op
    Info
    x
    x
    CtID=$CT.CTID;
    Hostname=
    $CT.HOSTNAME
    Die Verbindung zu einem Kartenterminal wurde hergestellt

    CT
    /DISCONNECTED
    Op
    Info
    x
    x
    CtID=$CT.CTID;
    Hostname=
    $CT.HOSTNAME
    Die Verbindung
    zu einem Kartenterminal
    wurde unterbrochen

    CT
    /TLS_ESTABLISHMENT_FAILURE
    $Error
    Type
    $Seve
    rity
    x
    x
    CtID = $CT.ID;
    Name=$CT. HOSTNAME;
    Error=$Fehlercode;
    Bedeutung=
    $Fehlertext
    Im Rahmen des
    Verbindungsaufbaus sind Fehler aufgetreten
    TUC_KON_050
    CT
    /CT_ADDING_ERROR
    $Error
    Type
    $Seve
    rity
    x
    x
    IP=$IP-Adresse;
    Name=$Hostname;
    Error=$Fehlercode;
    Bedeutung=
    $Fehlertext
    Bei dem Versuch ein KT der Verwaltung zuzufügen ist ein Fehler aufgetreten
    TUC_KON_054
    CT
    /SLOT_FREE
    Op
    Info
    -
    -
    CtID=$CT.CTID;
    SlotNo=
    $CT.SLOTS_USED[X]
    Internes Event von Kartenterminaldienst
    --> Kartendienst.
    Informiert, dass
    ein Slot frei wurde. Wird im Kartendienst
    ausgewertet und verursacht dort CARD/REMOVED

    CT
    /SLOT_IN_USE
    Op
    Info
    -
    -
    CtID=$CT.CTID;
    SlotNo=<FU-Nummer
    aus Ereignisnachricht>
    Internes Event
    von Kartenterminaldienst
    --> Kartendienst.
    Informiert, dass
    ein Slot belegt wurde. Wird im
    Kartendienst
    ausgewertet und verursacht dort
    CARD/INSERTED

    Kartendienst
    CARD
    /INSERTED
    Op
    Info
    x
    x
    CardHandle=
    $CARD.CARDHANDLE;
    CardType=$CARD.TYP;
    CardVersion=
    $CARD.VER;
    ICCSN=$CARD.ICCSN;
    CtID=$CARD.CTID;
    SlotID=
    $CARD.SLOTID;
    InsertTime=
    $CARD.INSERTTIME;
    CardHolderName=
    $CARD.CARD
    HOLDERNAME;
    KVNR=$CARD.KVNR
    Eine Karte wurde
    gesteckt
    TUC_KON_001
    (als Reaktion auf
    CTM
    /SLOT_IN_USE)
    CARD
    /REMOVED
    Op
    Info
    x
    x
    CardHandle=
    $CARD.CARDHANDLE;
    CardType=$CARD.TYP;
    CardVersion=
    $CARD.VER;
    ICCSN=$CARD.ICCSN;
    CtID=$CARD.CTID;
    SlotID=
    $CARD.SLOTID;
    InsertTime=
    $CARD.INSERTTIME;
    CardHolderName=
    $CARD.CARDHOLDER
    NAME;
    KVNR=$CARD.KVNR
    Eine Karte wurde
    gezogen
    Reaktion auf
    CTM/SLOT_FREE
    CARD
    /PIN
    /VERIFY_STARTED
    Op
    Info
    -
    x



    CARD
    /PIN
    /VERIFY_FINISHED
    Op
    Info
    -
    x



    CARD
    /PIN
    /CHANGE_STARTED
    Op
    Info
    -
    x



    CARD
    /PIN
    /CHANGE_FINISHED
    Op
    Info
    -
    x



    CARD
    /PIN
    /ENABLE_STARTED
    Op
    Info
    -
    x
    CardHandle=$;
    CardType=$;
    ICCSN=$;
    CtID=$;
    SlotID=$;
    PinRef=$PinRef;
    PinInputCtID
    =$PinInputKT
    PIN-Schutz
    anschalten beginnt
    TUC_KON_027
    CARD
    /PIN
    /ENABLE_FINISHED
    Op
    Info
    -
    x
    CardHandle=$;
    CardType=$;
    ICCSN=$;
    CtID=$;
    SlotID=$;
    PinRef=$PinRef;
    PinInputCtID
    =$PinInputKT
    PIN-Schutz anschalten wurde beendet
    TUC_KON_027
    CARD
    /PIN
    /DISABLE_STARTED
    Op
    Info
    -
    x
    CardHandle=$; CardType=$;
    ICCSN=$;
    CtID=$;
    SlotID=$;
    PinRef=$PinRef;
    PinInputCtID
    =$PinInputKT
    PIN-Schutz ausschalten beginnt
    TUC_KON_027
    CARD
    /PIN
    /DISABLE_FINISHED
    Op
    Info
    -
    x
    CardHandle=$; CardType=$;
    ICCSN=$;
    CtID=$;
    SlotID=$;
    PinRef=$PinRef;
    PinInputCtID
    =$PinInputKT
    PIN-Schutz ausschalten wurde beendet
    TUC_KON_027
    Systeminformationsdienst








    Verschlüsselungsdienst








    Signaturdienst
    SIG
    /SIGNDOC
    /NEXT_SUCCESSFUL
    Op
    Info
    -
    X
    $Jobnummer
    Die nächste Signatur aus einem
    Signaturstapel wurde erfolgreich
    erstellt.
    TUC_KON_166
    „nonQES Signaturen
    erstellen“
    TUC_KON_154
    „QES Signaturen erstellen“
    Zertifikatsdienst
    CERT
    /TSL
    /IMPORT
    Op
    Error
    x
    -
    $Fehlerbeschreibung
    Manueller Import der
    TSL fehlgeschlagen
    TUC_KON_032
    "TSL aktualisieren"
    CERT
    /TSL
    /UPDATED
    Op
    Info
    x
    -

    Eine neue TSL
    wurde erfolgreich in den TrustStore eingespielt
    TUC_KON_032
    "TSL aktualisieren"
    CERT
    /CRL
    /INVALID
    Op
    Error
    x
    -

    Prüfung der Signatur
    der CRL fehlgeschlagen
    TUC_KON_040
    "CRL aktualisieren"
    CERT
    /CRL
    /IMPORT
    Op
    Error
    x
    -
    $Fehlerbeschreibung
    Manueller Import der CRL fehlgeschlagen
    TUC_KON_040
    "CRL aktualisieren"
    CERT
    /CRL
    /UPDATED
    Op
    Info
    x
    -

    Die CRL wurde
    erfolgreich aktualisiert
    TUC_KON_040
    "CRL aktualisieren"
    CERT
    /CARD
    /EXPIRATION
    Op
    Warning
    x
    x
    CARD_TYPE=gSMC-K;
    ICCSN=$ICCSN;
    Konnektor=
    $MGM_KONN_HOSTNAME;
    ZertName=<Name des Zertifikatsobjekts>;
    Expiration
    Date=$validity
    gSMC-K abgelaufen
    TUC_KON_033
    "Zertifikatsablauf prüfen"
    CERT
    /CARD
    /EXPIRATION
    Op
    Warning
    -
    x
    CARD_TYPE=$Type;
    ICCSN=$ICCSN;
    CARD_HANDLE=
    $CardHandle;
    CardHolderName=
    $CardHolderName;
    ZertName=<Name des Zertifikatsobjekts>;
    ExpirationDate=
    $validity
    Sonstige Karte abgelaufen
    TUC_KON_033
    "Zertifikatsablauf prüfen"
    CERT
    /CARD
    /EXPIRATION
    Op
    Info
    -
    x
    CARD_TYPE=gSMC-K;
    ICCSN=$ICCSN;
    Konnektor=
    $MGM_KONN_HOSTNAME;
    ZertName=<Name des Zertifikatsobjekts>; ExpirationDate=
    $validity;
    DAYS_LEFT=
    $validity-$Today
    gSMC-K läuft innerhalb von
    DAYS_LEFT Tagen ab
    TUC_KON_033
    "Zertifikatsablauf prüfen"
    CERT
    /CARD
    /EXPIRATION
    Op
    Info
    -
    x
    CARD_TYPE=$Type;
    ICCSN=$ICCSN;
    CARD_HANDLE=
    $CardHandle;
    CardHolderName=
    $CardHolderName;
    ZertName=<Name des Zertifikatsobjekts>;
    ExpirationDate=
    $validity;
    DAYS_LEFT=
    $validity-$Today
    Sonstige Karte läuft innerhalb von DAYS_LEFT Tagen ab
    TUC_KON_033
    "Zertifikatsablauf prüfen"
    CERT
    /BNETZA_VL
    /UPDATED
    Op
    Info
    x
    -

    Eine neue BNetzA-VL wurde erfolgreich in den TrustStore eingespielt
    TUC_KON_031
    " BNetzA-VL aktualisieren"
    CERT
    /BNETZA_VL
    /IMPORT
    Op
    Error
    x
    -
    $Fehlerbeschreibung
    Manueller Import der
    BNetzA-VL fehlgeschlagen
    TUC_KON_031
    " BNetzA-VL aktualisieren"
    Protokollierungsdienst
    LOG
    /ERROR
    $Error
    Type
    $Seve
    rity
    -
    -
    Error=$Fehlercode
    Im Protokollierungsdienst auftretende Fehler werden verteilt
    TUC_KON_271
    LOG
    /CRYPTO_OP
    Sec
    Info
    x
    -
    Operation=
    $Operationsname;
    <für alle betroffenen Schlüssel:>
    Karte=$ICCSN;
    Keyref=<Referenz auf den Schlüssel>;
    CARD_HANDLE=
    $CardHandle;
    CardHolderName=
    $CardHolderName


    TLS-Dienst








    Anbindung LAN/WAN
    ANLW
    /LAN
    /IP_CHANGED
    Op
    Warning
    x
    -
    IP=$dieNeueIP
    Wenn der LAN-Adapter eine neue IP oder Netzwerk bekommen hat
    DHCP,
    Management
    schnittstelle
    ANLW
    /WAN
    /IP_CHANGED
    Op
    Info
    x
    -
    IP=$dieNeueIP
    Wenn der WAN-Adapter eine neue IP oder Netzwerk bekommen hat
    DHCP,
    Management
    schnittstelle
    DHCP-Server
    DHCP
    /SERVER
    /STATECHANGED
    Op
    Info
    x
    x
    STATE=
    $DHCP_SERVER_STATE

    Administrator
    DHCP Client
    DHCP
    /LAN_CLIENT
    /RENEW
    Op
    Info
    x
    x
    IP_ADDRESS=
    <Belegung>

    TUC_KON_341
    DHCP
    /WAN_CLIENT
    /RENEW
    Op
    Info
    x
    x
    IP_ADDRESS=
    <Belegung>

    TUC_KON_341
    DHCP
    /LAN_CLIENT
    /STATECHANGED
    Op
    Info
    x
    x
    STATE=
    $DHCP_CLIENT_
    LAN_STATE


    DHCP
    /WAN_CLIENT
    /STATECHANGED
    Op
    Info
    x
    x
    STATE=
    $DHCP_CLIENT_
    WAN_STATE


    VPN-Client
    NETWORK
    /VPN_TI
    /UP
    Op
    Info
    x
    x

    Wenn der VPN-Tunnel zur TI erfolgreich aufgebaut
    worden ist.

    NETWORK
    /VPN_TI
    /DOWN
    Op
    Info
    x
    x

    Wenn der VPN-Tunnel zur TI nicht mehr zur Verfügung steht.
    AFO
    NETWORK
    /VPN
    /CONFIG_CHANGED
    Op
    Info
    x
    -

    Wenn die Konfiguration des VPN-Clients angepasst wurde.
    Management
    schnittstelle
    NETWORK
    /VPN_SIS
    /UP
    Op
    Info
    x
    x

    Wenn der VPN-Tunnel zum
    SIS erfolgreich aufgebaut worden ist.

    NETWORK
    /VPN_SIS
    /DOWN
    Op
    Info
    x
    x

    Wenn der VPN-Tunnel zum SIS nicht mehr zur
    Verfügung steht.
    AFO
    Zeitdienst
    NTP
    /ENTERCRITICALSTATE
    Op
    FATAL
    x
    -
    MESSAGE=
    „CRITICALTIME
    DEVIATION”
    Zeitabweichung von mehr als einer Stunde entdeckt

    Namensdienst und Dienstlokalisierung








    Leistungsumfänge und Standalone-Szenarios
    MGM
    /ADMINCHANGES
    Op
    Info
    x
    -
    User=
    $AdminUsername;
    RefID=$ReferenzID;
    NewVal=
    $NeuEingestellter
    Wert“
    Änderungen die der Admin vornimmt werden protokolliert

    MGM
    /CONFIG_EXIMPORT
    Op
    Info
    x
    -
    User=
    $AdminUsername;
    Mode=
    [Export/Import]
    Dokumentiert (via Mode), dass die Konnektor
    konfiguration
    exportiert oder importiert wurde.

    MGM
    /FACTORYSETTINGS
    Op
    Info
    x
    -
    User=
    $AdminUsername
    Ein ausgelöster Werksreset wird protokolliert

    MGM
    /REMOTE_SESSION
    Op
    Info
    x
    -
    InitUser=
    $AdminUsername;
    RemoteID=<Kennung der Gegenstelle>;
    Mode=
    [InitSuccess/
    InitFail/Exit]
    Protokollierung des Versuchs, des Beginns und des Endes einer Remote-
    Management Session

    MGM
    /LU_CHANGED
    /LU_ONLINE
    Op
    Info
    x
    x
    Active=
    $MGM_LU_ONLINE
    Leistungsumfang Online wurde aktiviert/
    deaktiviert
    Administrator
    MGM
    /LU_CHANGED
    /LU_SAK
    Op
    Info
    x
    x
    Active=
    $MGM_LU_SAK
    Leistungsumfang Signatur
    anwendungs
    komponente wurde aktiviert/deaktiviert
    Administrator
    MGM
    /STANDALONE_CHANGED
    Op
    Info
    x
    x
    Active=
    $MGM_STANDALONE_KON
    Festlegung des Konnektors als "Alleinstehend"
    wurde geändert
    Administrator
    In- und Außerbetriebnahme, Registrierung
    MGM
    /TI_ACCESS_GRANTED
    Op
    Info
    x
    x
    Active=
    $MGM_TI_ACCESS_
    GRANTED
    Der Konnektor wurde erfolgreich freigeschaltet
    Administrator
    TUC_KON_411

    SMC_K/REGISTER/ERROR Op Error x x Iccsn=$Iccsn;
    Serial=$SerialnumberNK;
    Operation=Register | Deregister;
    Fail=No_Smcb | Other
    Fehler bei Registrierung TUC_KON_411
    Software- Aktualisierungsdienst (KSR-Client)
    KSR
    /ERROR
    $Error
    Type
    $Seve
    rity
    x
    x
    Target=Konnektor;
    Name=
    <MGM_KONN_HOSTNAME>;
    Error=$Fehlercode;
    Bedeutung=
    $Fehlertext
    Während der Konnektor
    aktualisierung ist ein Fehler aufgetreten
    TUC_KON_280
    KSR
    /ERROR
    $Error
    Type
    $Seve
    rity
    x
    x
    Target=KT;
    Name=
    <KT-Friendly Name>;
    CtID=$ctID;
    Error=$Fehlercode;
    Bedeutung=
    $Fehlertext
    Während einer Kartenterminal
    aktualisierung ist ein Fehler aufgetreten
    TUC_KON_281
    KSR
    /ERROR
    $Error
    Type
    $Seve
    rity
    x
    x
    Error=$Fehlercode;
    Bedeutung=
    $Fehlertext
    Im KSR-Client ist ein Fehler aufgetreten
    TUC_KON_282
    KSR
    /UPDATE
    /START
    Sec
    Info
    x
    x
    für TUC_KON_280
    Target=Konnektor;
    Name=
    <MGM_KONN_HOSTNAME>

    für TUC_KON_281
    Target=KT;
    CtID=$CtID
    Ein Updateprozess im Konnektor wird gestartet, Ziel Konnektor oder Kartenterminal
    TUC_KON_280
    TUC_KON_281
    KSR
    /UPDATE
    /SUCCESS
    Sec
    Info
    x
    x
    für TUC_KON_280
    Target=Konnektor;
    Name=
    <MGM_KONN_HOSTNAME>;
    NewFirmwareversion=
    <UpdateInformation.
    FirmwareVersion>;
    ConfigurationChanged
    =<Ja/Nein>;
    ManualInputNeeded=
    <Ja/Nein>

    für TUC_KON_281
    Target=KT;
    Name=
    <KT-FriendlyName>;
    CtID=$ctID;
    NewFirmwareversion=
    <UpdateInformation.
    FirmwareVersion>
    Die Firmware des Konnektors/
    eines Kartenterminals wurde erfolgreich aktualisiert
    TUC_KON_280
    TUC_KON_281
    KSR
    /UPDATE
    /END
    Sec
    Info
    x
    x
    für TUC_KON_280
    Target=Konnektor;
    Name=
    <MGM_KONN_HOSTNAME>

    für TUC_KON_281
    Target=KT;
    CtID=$CtID
    Ein Updateprozess im Konnektor wurde beendet
    TUC_KON_280
    TUC_KON_281
    KSR
    /UPDATE
    /KONNEKTOR_DOWNLOAD_END
    Op
    Info
    x
    x
    Je heruntergeladenem FW-Paket:
    ProductVendorID=
    $UpdateInformation/
    ProductVendorID;
     
    ProductCode=
    $UpdateInformation/
    ProductCode;
     
    ProductName=
    $UpdateInformation/
    ProductName;
     
    FirmwareVersion=
    $UpdateInformation/
    Firmware/FWVersion;
     
    Deadline=
    $UpdateInformation/
    DeploymentInformation/
    Deadline;
     
    FWPriority=
    $UpdateInformation/
    Firmware/FWPriority;
     
    FirmwareReleaseNotes=
    $UpdateInformation/
    Firmware/
    FirmwareReleaseNotes
    Download der Konnektor Firmware abgeschlossen
    TIP1-A_6025
    KSR
    /UPDATES_AVAILABLE
    Op
    Info
    -
    x
    Je gefundenem
    FW-Paket:
    ProductVendorID=
    $UpdateInformation/
    ProductVendorID;

    ProductCode=
    $UpdateInformation/
    ProductCode;

    ProductName=
    $UpdateInformation/
    ProductName;

    FirmwareVersion=
    $UpdateInformation/
    FirmwareVersion;

    Deadline=
    $UpdateInformation/
    DeploymentInformation/
    Deadline;
     
    FWPriority=
    $UpdateInformation/
    Firmware/FWPriority;
    FirmwareReleaseNotes=
    $UpdateInformation/
    Firmware/
    FirmwareReleaseNotes
    Ein oder mehrere Updates auf neuere Versionen sind verfügbar
    TIP1-A_4836
    KSR
    /UPDATE_KONFIG
    Op
    Info
    x
    -
    AlteVersion, NeueVersion
    Aktualisierung Bestandsnetze
    TUC_KON_283

    Die Abbildungsvorschrift von Fehler- auf Event-Type lautet:

    8 Anhang H – Mapping von „Architektur der TI-Plattform“ auf Konnektorspezifikation

    Tabelle 393: TAB_KON_711 Architektur der TI-Plattform, Berechtigt Fachmodule

    Interface
    Operation

    Funktionsmerkmal
    Interface
    I_Cert_Verification
    verify_Certificate

    Zertifikatsdienst
    TUC_KON_037
    "Zertifikat prüfen"
    I_Crypt_Operations
    decrypt_Document

    Verschlüsselungsdienst
    TUC_KON_071
    "Daten hybrid entschlüsseln"
    encrypt_Document

    TUC_KON_070
    "Daten hybrid verschlüsseln"
    I_DNS_Name_Information
    get_FQDN

    Namensdienst und Dienstlokalisierung
    TUC_KON_364
    „DNS Reverse Lookup
    durchführen“
    get_IP_Address

    TUC_KON_361
    „DNS Namen auflösen“
    get_Service_Information

    Namensdienst und
    Dienstlokalisierung
    TUC_KON_362
    „Liste der Dienste abrufen“
    TUC_KON_363
    „Dienstdetails
    abrufen“
    I_IP_Transport
    send_Data_TI



    I_KT_Operations
    interact_with_User

    Kartenterminaldienst
    TUC_KON_051
    "Mit Anwender über
    Kartenterminal interagieren"
    I_KV_Card_Handling
    discard_Card_Usage_Reference

    ---
    --- keine Umsetzung
    notwendig.
    Erfolgt implizit
    get_Card_Usage_Reference

    ---
    --- keine Umsetzung
    notwendig.
    Erfolgt implizit
    I_KV_Card_Operations
    decrypt_Data

    Kartendienst
    TUC_KON_219
    "Entschlüssele"
    do_Reset

    TUC_KON_024
    "Karte zurücksetzen"
    erase_Card_Data

    TUC_KON_211
    „LöscheRecordInhalt“
    TUC_KON_204
    „LöscheDateiInhalt“
    extract_card_data

    Zertifikatsdienst
    TUC_KON_034
    "Zertifikatsinformationen
    extrahieren"
    read_Card_Data

    Kartendienst
    TUC_KON_202
    "LeseDatei"


    TUC_KON_209
    "LeseRecord"


    TUC_KON_215
    "SucheRecord"
    read_KVK

    TUC_KON_202
    "Lese Datei"
    send_APDU

    TUC_KON_200
    "SendeAPDU"
    sign_Data

    TUC_KON_218
    "Signiere"
    verify_eGK

    TUC_KON_018
    "eGK-Sperrung prüfen"
    write_Card_Data

    TUC_KON_203
    "SchreibeDatei"


    TUC_KON_210
    "SchreibeRecord"


    TUC_KON_214
    "FügeHinzuRecord"
    write_eGK_Protocol

    TUC_KON_006
    "Datenzugriffsaudit eGK schreiben"
    I_KV_Card_Reservation
    handle_Session

    Kartendienst
    TUC_KON_023
    "Karte reservieren"
    I_KV_Card_Unlocking
    authorize_Card

    Kartendienst
    TUC_KON_005
    "Card-to-Card authentisieren"
    change_PIN

    TUC_KON_019
    "PIN ändern"
    enable_PIN
    disable_PIN

    TUC_KON_027
    „PIN-Schutz ein-/
    ausschalten”
    do_C2C

    TUC_KON_005
    "Card-to-Card
    authentisieren"
    get_PIN_Status

    TUC_KON_022
    "Liefere PIN-Status"
    initialize_PIN

    TUC_KON_019
    "PIN ändern"
    unblock_PIN

    TUC_KON_021
    "PIN entsperren"
    verify_PIN

    TUC_KON_012
    "PIN verifizieren"
    I_Notification_From_FM
    notify

    Systeminformationsdienst
    TUC_KON_256
    "Systemereignis
    absetzen"
    I_Local_Storage
    write_Data
    read_Data
    erase_Data

    Konnektormanagement
    TIP1-A_5484
    I_Poll_System_Information
    get_Ressource_Information

    Systeminformationsdienst
    TUC_KON_254
    "Liefere
    Ressourcendetails"
    get_Ressource_List

    TUC_KON_252
    "Liefere KT_Liste"
    get_Ressource_List

    TUC_KON_253
    "Liefere Karten_Liste"
    I_Reg_Notification
    register_for_Notifications

    ---
    --- keine Umsetzung
    notwendig.
    Erfolgt implizit
    I_Role_Information
    get_Role

    Kartendienst
    TUC_KON_036
    „LiefereFachlicheRolle“
    I_SAK_Operations
    sign_Document_QES

    Signaturdienst
    TUC_KON_150
    „Dokumente QES
    signieren“
    verify_Document_QES

    TUC_KON_151
    "QES Dokumentensignatur prüfen"
    I_Sign_Operations
    sign_Document

    Signaturdienst
    TUC_KON_160
    „Dokumente nonQES signieren“
    external_Authenticate

    TUC_KON_160
    „Dokumente nonQES signieren“
    verify_Document

    TUC_KON_161
    „nonQES Dokumentsignatur prüfen“
    get_Certificate

    Kartendienst
    TUC_KON_216
    „LeseZertifikat“
    I_Symm_Crypt_Operations
    decrypt_Document_Symmetric

    Verschlüsselungsdienst
    TUC_KON_073
    "Daten symmetrisch
    entschlüsseln"
    encrypt_Document_Symmetric

    TUC_KON_072
    "Daten symmetrisch
    verschlüsseln"
    I_Synchronised_System_Time
    get_Time

    Zeitdienst
    TUC_KON_351
    "Liefere Systemzeit"
    I_TLS_Client
    send_Secure

    TLS-Dienst
    TUC_KON_110
    "Kartenbasierte
    TLS-Verbindung
    aufbauen"


    TUC_KON_111
    "Kartenbasierte
    TLS-Verbindung
    abbauen"


    Anbindung LAN/WAN
    AFOs: Routing
    der IP-Pakete von
    Fachmodul
    (=Konnektor intern)
    --> VPN_TI
    I_Directory_Query
    search_Directory

    LDAP-Proxy
    TUC_KON_290
    „LDAP-Verbindung
    aufbauen“


    TUC_KON_291
    „Verzeichnis abfragen“


    TUC_KON_292
    „LDAP-Verbindung
    trennen"


    TUC_KON_293
    „Verzeichnisabfrage
    abbrechen"
    I_KSRC_FM_Support
    list_available_Packages

    Software-Aktualisierung
    (KSR-Client)
    TUC_KON_285
    „UpdateInformationen für Fachmodul beziehen"
    load_Package

    TUC_KON_286
    „Paket für Fachmodul laden“

    Tabelle 394: TAB_KON_712 Architektur der TI-Plattform, Berechtigt Clientsysteme

    Interface
    Operation

    Funktionsmerkmal
    Interface:Operation
    I_Crypt_Operations
    decrypt_Document

    Verschlüsselungsdienst
    EncryptionService
    :DecryptDocument
    encrypt_Document

    EncryptionService
    :EncryptDocument
    I_DNS_Name_Resolution
    get_FQDN

    Namensdienst und Dienstlokalisierung
    GetFQDN
    get_IP_Address

    GetIPAddress
    I_IP_Transport
    send_Data_External

    Anbindung LAN/WAN
    AFOs:
    Routing der IP-Pakete von Client
    --> VPN_SIS
    I_KV_Card_Handling
    discard_Card_Usage_Reference

    ---
    --- keine Umsetzung notwendig.
    Erfolgt implizit
    get_Card_Usage_Reference

    ---
    --- keine Umsetzung
    notwendig.
    Erfolgt implizit
    I_KV_Card_Unlocking
    change_PIN

    Kartendienst
    CardService
    :ChangePin
    disable_PIN

    CardService
    :EnablePin
    enable_PIN

    CardService
    :DisablePin
    get_PIN_Status

    CardService
    :GetPinStatus
    initialize_PIN

    CardService
    :ChangePin
    unblock_PIN

    CardService
    :UnblockPin
    verify_PIN

    CardService
    :VerifyPin
    I_Poll_System_Information
    get_Ressource_Information

    Systeminformationsdienst
    EventService
    :GetResourceInformation
    get_Ressource_List

    EventService
    :GetCardTerminals
    get_Ressource_List

    EventService
    :GetCards
    I_Reg_Notification
    register_for_Notifications

    Systeminformationsdienst
    EventService
    :Subscribe


    EventService
    :Unsubscribe


    EventService
    :GetSubscription
    I_SAK_Operations
    sign_Document_QES

    Signaturdienst
    SignatureService
    :SignDocument
    verify_Document_QES

    SignatureService
    :VerifyDocument
    I_Sign_Operations
    sign_Document

    Signaturdienst
    SignatureService
    :SignDocument
    verify_Document

    SignatureService
    :VerifyDocument
    external_Authenticate

    Authentifizierungsdienst
    AuthSignatureService
    :ExternalAuthenticate
    get_Certificate

    Zertifikatsdienst
    CertificateService
    :ReadCardCertificate
    I_NTP_Time_Information
    sync_Time

    Zeitdienst
    I_NTP_Time_Information
    :sync_Time
    I_Directory_Query
    search_Directory

    LDAP-Proxy
    LDAP-Operation
    (TIP1-A_5521)

    Tabelle 395: TAB_KON_713 Architektur der TI-Plattform, Berechtigt eHealth-KT

    Interface
    Operation

    Funktionsmerkmal
    Interface:Operation
    I_Notification
    notify

    SICCT
    Ereignisdienst
    :SICCT-Ereignisnachrichten


    SICCT
    Ereignisdienst
    :ServiceAnnouncement

    Tabelle 396: TAB_KON_714 Architektur der TI-Plattform, Berechtigt Administrator

    Interface
    Operation
    ->
    Funktionsmerkmal
    Interface:Operation
    I_Change_System_Time
    set_System_Time
    ->
    Zeitdienst
    TIP1-A_4793
    Konfigurierbarkeit des
    Konnektor NTP-Servers
    I_Facade_Access_Configuration
    add_Clientsystem
    ->
    Fachliche Anbindung der
    Clientsysteme
    TIP1-A_4518
    Konfiguration der Anbindung Clientsysteme
    remove_Clientsystem
    set_CS_Access_Mode
    I_KSRC_Local_Management
    do_local_Update
    ->
    Software-Aktualisierung
    (KSR-Client)
    TUC_KON_280 "Konnektoraktualisierung
    durchführen"
    I_KSRC_Management
    do_Update
    ->
    Software-Aktualisierung
    (KSR-Client)
    TUC_KON_280 "Konnektoraktualisierung durchführen"
    TUC_KON_281
    "Kartenterminalaktualisierung anstoßen"
    list_available_Updates
    TUC_KON_282
    "Update Informationen beziehen"
    I_KTV_Management
    configure_KTs
    ->
    Kartenterminalverwaltung
    Managementschnittstelle
    :TIP1-A_4555
    Manuelles Hinzufügen eines Kartenterminals
    Managementschnittstelle
    :TIP1-A_4540
    Reaktion auf KT Service
    Announcement
    Managementschnittstelle
    :TIP1-A_4556
    Pairing mit Kartenterminal
    durchführen
    Managementschnittstelle
    :TIP1-A_4557
    Ändern der Korrelationswerte eines Kartenterminals

    9 Anhang I – Umsetzungshinweise (informativ)

    In diesem Anhang finden sich Darstellungen und Informationen, die ein Konnektorhersteller zur Umsetzung der normativen Anforderungen in ein konkretes Produkt berücksichtigen kann. Sie wurden im Rahmen der Erhebung der normativen Anforderungen erarbeitet, um die Umsetzbarkeit der Anforderungen zu bestätigen.

    Dieser Anhang soll als Unterstützung für eine Umsetzung verstanden werden und erhebt keinen Anspruch auf Korrektheit und Vollständigkeit.

    9.1 Systemüberblick

    9.1.1 – Hinweise zur Sicherheitsevaluierung nach Common Criteria

    Gemäß dem Sicherheitskonzept des Konnektors [gemKPT_Sich_Kon] muss die Software des Konnektors nach Common Criteria (CC) evaluiert und geprüft werden.

    Diese Software erbringt Sicherheitsleistungen in zwei wesentlichen Funktionsblöcken. Durch diese Aufteilung ist es möglich, dass die einzelnen Funktionsblöcke zeitlich voneinander unabhängig bzw. sogar von unterschiedlichen Herstellern implementiert, evaluiert und geprüft werden können. Es werden zwei Schutzprofile (Protection Profile) für die Funktionsblöcke des Konnektors erstellt. Es handelt sich dabei um die Schutzprofile des Netzkonnektors (KONN.NK) sowie des Anwendungskonnektors (KONN.AK) inklusive der Signaturanwendungskomponente. Das Schutzprofil des Sicherheitsmoduls für den Konnektor (SM-K) wird in diesem Kapitel nicht betrachtet.

    Diese Schutzprofile definieren eine implementierungsunabhängige Menge von Sicherheitsanforderungen für die einzelnen Konnektorfunktionsblöcke bzw. Konnektorbestandteile. Anhand dieser Schutzprofile werden von den Herstellern der Konnektoren die Sicherheitsvorgaben (Security Targets) für die konkreten Umgebungen erstellt, welche als Eingangsdokumente für den Zertifizierungsprozess der jeweiligen konkreten Komponenten eingesetzt werden. Diese zu evaluierenden Komponenten werden als Evaluierungsgegenstand (EVG) bezeichnet.

    9.1.1.1 Separationsmechanismen des Konnektors

    Damit es nach einer erfolgreichen Evaluierung eines Konnektors auch weiterhin möglich bleibt, Software oder Daten, die keinen direkten Einfluss auf Sicherheitsfunktionen der EVGs aufweisen, ohne eine Re-Evaluierung definiert auszutauschen, hinzuzufügen oder zu erweitern, ist eine Separation der Komponenten des EVG dringend anzuraten.

    Implementiert der Hersteller keine bzw. nicht ausreichende Separationsmechanismen, so ist bei bestimmten Update-Arten von einer aufwändigen Re-Evaluierung des entsprechenden EVGs auszugehen. Die Separation dient also der Trennung zwischen ausführbarem Code des EVG, welcher Sicherheitsfunktionen umsetzt, und zusätzlichem ausführbarem Code auf dem Konnektor, welcher keine Sicherheitsfunktionen umsetzt.

    Die Wahl der Separationsmechanismen steht dem Hersteller frei und muss in den Sicherheitsvorgaben für den EVG beschrieben und als solcher evaluiert werden. Aus diesen Sicherheitsvorgaben ergibt sich auch, welche Update-Arten bei welchen Separationsmechanismen eine Re-Evaluierung des EVG erfordern und wie aufwendig diese Re-Evaluierung ausfällt.

    Unter diese Update-Arten können beispielsweise – je nach Konnektorarchitektur, CC-Dokumentation oder Konnektorimplementierung – Bestandteile des unter dem Konnektor arbeitenden Betriebsystems, die Installation dezentraler Komponenten von Fachlogik oder Konfigurationsdaten des Konnektors fallen.

    Als Beispiel für Separationsmechanismen sei auf die folgende informative Aufzählung verwiesen, welche jedoch keinen Anspruch auf Vollständigkeit besitzen kann und nur mögliche Alternativen aufzeigt:

    Je nach gewähltem Architekturansatz des Herstellers sind nicht alle hier genannten Alternativen für die Separation des EVG auf dem Konnektor anwendbar.

    Insbesondere sollte der Hersteller den eigentlichen Update-Prozess und die dafür verantwortliche Komponente mit besonderer Sorgfalt beschreiben, spezifizieren und implementieren. Bei einer fehlerhaften Implementierung dieser Komponente besteht die Gefahr einer Schwächung oder des Ausschaltens von Sicherheitsfunktionen des EVG. Die Update-Komponente muss eine sichere Zuweisung der Updates zu den separierten Bestandteilen des EVGs gewährleisten. Auch ist zu betonen, dass der EVG immer die Integrität der Daten des Updates und die Authentizität des Absenders prüfen muss, bevor ein Update akzeptiert wird. Der Update-Komponente muss somit besondere Beachtung geschenkt werden.

    9.1.1.2 Granularität der TSF

    Die TSF (TOE Security Functionality) eines EVG besteht aus Subsystemen und Modulen, wobei ein Modul die genaueste Beschreibung einer Funktionalität darstellt und unterhalb der Subsysteme angesiedelt ist. Subsysteme beschreiben das Design des EVG und können wiederum – je nach Komplexität eines EVGs – aus weiteren Subsystemen bestehen. Ein Entwickler sollte außer der Modulbeschreibung keine weiteren Informationen zur Implementierung der dort beschriebenen Funktionalität benötigen.

    Die Subsysteme und Module der TSF gliedern sich in drei Klassen:

       (a) SFR-Enforcing Subsysteme und Module. Hierunter fallen die Subsysteme und

            Module, welche eine funktionale Sicherheitsanforderung direkt durchsetzen.

       (b) SFR-Supporting Subsysteme und Module. Hierunter fallen die Subsysteme und

            Module, welche bei der Durchsetzung einer funktionalen Sicherheitsanforderung

            unterstützend wirken.

       (c) SFR-Non-Interfering Subsysteme und Module. Hierunter fallen die Subsysteme

            und Module, welche keine Leistung bei der Erfüllung einer funktionalen

            Sicherheitsanforderung erbringen.

    Sollte nach einer erfolgreichen CC-Evaluierung eines Konnektors die Notwendigkeit zur Änderung der Software des Konnektors gegeben sein, so ist unter Umständen eine Re-Evaluierung des EVG erforderlich. Diese Notwendigkeit kann sich aus der Behebung von nachträglich erkannten Fehlern, aufgetretenen Sicherheitslücken, Schwächen eines Standardverfahrens oder einer erforderlichen Erweiterung der Funktionalität ergeben.

    Im Rahmen der Aufzählung der Anforderungen an die Beschreibung des EVG-Design (ADV_TDS) wird bereits die Aufteilung der TSF auf Subsysteme und Module beschrieben. Trotzdem soll hiermit ausdrücklich geraten werden, die Aufteilung der TSF auf die Subsysteme und Module selbst und die Aufteilung der Subsysteme und Module auf die drei o. g. Klassen möglichst feingranular durchzuführen.

    Denn so

    1. können einfacher umfassende Tests durchgeführt und die Testabdeckung sichergestellt werden,
    2. kann bei der Veränderung von Programmcode der Evaluator die Auswirkungen auf SFR-Enforcing, Supporting oder Non-Interfering SFRs einfacher herausfinden und damit die Kosten und den zeitlichen Aufwand einer Re-Evaluierung senken.
    3. kann bei der Veränderung von Programmcode, welcher als SFR-Non-Interfering eingestuft wird, das Maintenance-Verfahren anstelle einer Re-Evaluierung angewandt werden, welches einen erheblichen zeitlichen und damit auch monetären Vorteil gegenüber dem Re-Evaluierungsverfahren darstellt.

    9.2 Übergreifende Festlegungen

    9.2.1 Interne Mechanismen

    9.2.1.1 Zufallszahlen und Schlüssel

    Der Konnektor kann zur Erzeugung von Zufallszahlen und Einmalschlüsseln einen Hardware- oder Software-Generator verwenden. Als Quelle für Zufallszahlen kann der Konnektor die gSMC-K verwenden.

    9.3 Funktionsmerkmale

    9.3.1 Anwendungskonnektor

    9.3.1.1 Administration des Informationsmodells

    Wie die Administration der persistenten Entitäten und Beziehungen des Informationsmodells im Detail über die bereitzustellende Administrationsoberfläche erfolgt, entscheidet der Hersteller.

    Es wird folgende Reihenfolge für die Pflege des Informationsmodells empfohlen.

    1. Mandantenübergreifende Administration:
    2. Mandantenbezogene Administration:
    9.3.1.2 Vorgehensvariante für das Handling von CardSessions

    Das in der [TIP1-A_4560] „Rahmenbedingungen für Kartensitzungen“ geforderte Verhalten, ließe sich über folgenden Mechanismus umsetzen:

    Verschiedene Clientsystem (oder verschiedene Nutzer an einem Clientsystem) möchten auf Daten der über CardHandle adressierten Smartcard zugreifen.

    Für die Zugriffe müssen, je nach Definition der Zugriffsbedingung in der Zielkarte, bestimmte Sicherheitszustände erreicht werden (durch Verifikation einer PIN oder durch C2C). Diese erreichten Sicherheitszustände werden innerhalb einer Karte jeweils an einen logischen Kanäle (bzw. den Basiskanal) gebunden, d. h., das Erhöhen oder Absenken eines Sicherheitszustands wirkt nicht außerhalb des logischen Kanals, in dem die Veränderung verursacht wurde.

    Finden nun Clientsystemzugriffe in unterschiedlichen Kontexten (Mandant, Clientsystem, Arbeitsplatz und Nutzer verschieden) auf die gleiche Karte statt, so muss sichergestellt sein, dass PIN-Eingaben und durchgeführte C2C nur für den Kontext wirksam sind, in welchem sie durchgeführt wurden. Dies ließe sich erreichen, wenn jeder Kontext auf einen eigenen logischen Kanal der Karte abgebildet würde. Leider unterstützen der HBA und die SMC-B nur vier, die eGK nur einen logischen Kanal. Mehrere gleichzeitige unterschiedliche Kontexte wären somit nicht möglich.

    Eine mögliche Lösung für beliebig viele gleichzeitige Kontexte:


    Abbildung 23: PIC_KON_120 Abbildung von CardSessions auf logische Kanäle

    Der Kartendienst fungiert als Multiplexer. Er spiegelt die Zugriffsrechte der Karte und wendet deren Regeln selbständig gegen die unterschiedlichen Zugriffe durch Clientsysteme an.

    Für jedes Card-Objekt wird „in Richtung Clientsystem“ pro Kontext genau eine CardSession erzeugt und verwaltet. Zugriffe des Clientsystems erfolgen somit „im Kontext“ einer CardSession.

    In Richtung Karte verwendet das Card-Object genau zwei Kanäle (zwei logische oder einen logischen und einen Basiskanal):

    In jeder CardSession werden die in ihrem Kontext erreichten Sicherheitszustände vermerkt. Das Vorgehen für die Durchführung der Verifikationen und des Vermerkens der erreichten Sicherheitszustände, sowie der Datenzugriffe folgt folgenden Regeln (hier für PIN-Verifikation, sinngleich auch für C2C):

    Diese Regeln führen dazu, dass eine durch CardSession Y fehlgeschlagene Verifikation für PinRef_A die zuvor erfolgreich durch CardSession X durchgeführt Verifikation nicht beeinflusst. Kartenzugriffe auf dem Datenkanal sind für CardSession X weiterhin möglich, da der Verlust des erhöhten Sicherheitszustands durch fehlerhafte Verifikation immer nur im Verifikationskanal erfolgt.

    Dieser Mechanismus funktioniert mit zwei Kanälen zu einer Karte für beliebig viele CardSessions.

    9.3.1.3 Darstellung von Terminal-Anzeigen auf einem Kartenterminal

    Hiweise für die korrekte Verwendung der zur Verfügung stehenden Datenobjekte (DO) zur Darstellung von Terminal-Anzeigen an einem Kartenterminal finden sich in SICCT- (insbesondere in [SICCT#5.5.10.19] und [SICCT#5.5.10.21]) und eHealth-Kartenterminal-Spezifikationen.

    10 Anhang K – Szenarien im dezentralen Umfeld

    Die folgenden Szenarien für den Einsatz der Produkte der Telematikinfrastruktur beschreiben informativ Varianten und Optionen, die durch die Spezifikationen abgedeckt werden.

    Die vorliegenden Abbildungen in diesem Anhang fokussieren auf das dezentrale Umfeld und verzichten daher auf die Darstellung der zentralen Anteile, wie das zentrale Netzwerk der Telematikinfrastruktur, welches über den „VPN-Konzentrator TI“ erreichbar ist.

    Der Konnektor, sowie die Netzwerkkomponenten Switch und IAG (Internet Access Gateway) sind in den folgenden Szenarien zum Schutz vor unerlaubtem Zugriff gemäß den Annahmen des Sicherheitskonzeptes vor unbefugten physischen Zugriffen geschützt installiert.

    Die folgenden Abschnitte stellen jeweils ein Szenario in der Übersicht als Diagramm, eine Beschreibung sowie eine kurze Auflistung der Voraussetzungen und Auswirkungen dar.

    10.1 Szenario 1: Einfache Installation ohne spezielle Anforderungen und ohne bestehende Infrastruktur


    Abbildung 24: Szenario einer einfachen Installation

    10.1.1 Beschreibung des Szenarios

    Abbildung 25 zeigt ein einfaches Szenario für das dezentrale Umfeld. Es wird der Konnektor als Default-Gateway für jegliche IP-Kommunikation aus dem LAN in das WAN eingesetzt. Dabei übernimmt der Konnektor das Routing der Kommunikation in das Internet über den SIS (Secure Internet Service) und in die an die TI angeschlossenen Bestandsnetze. Die Bezeichnung IAG (Internet Access Gateway) steht für die Geräte, die den Internetzugang ermöglichen und typischerweise vom Internet Service Provider (ISP) zur Verfügung gestellt werden (z.B. DSL Router und DSL Modem).

    Ein oder mehrere Clientsysteme können über den Konnektor Anwendungsfälle der Telematikinfrastruktur initiieren und über den Konnektor und die zentrale TI-Plattform in Bestandsnetze kommunizieren (rote gestrichelte Linie). Dabei ist die Nutzung der Anwendungsfälle der Telematikinfrastruktur je nach Konfiguration des Konnektors entweder nur authentifizierten Clients möglich oder beliebigen Clients.

    In diesem einfachen Szenario werden über ein einziges Kartenterminal die SMC-B, der HBA und auch die eGK des Versicherten gelesen, es können dazu alternativ auch mehrere Kartenterminals genutzt werden.

    Darüber hinaus können die Clientsysteme über den SIS (Secure Internet Service) auf Dienste des Internets zugreifen.

    10.1.2 Voraussetzungen

    10.1.3 Auswirkungen

    10.2 Szenario 2: Installation mit mehreren Behandlungsräumen


    Abbildung 25: Szenario einer Installation mit mehreren Behandlungsräumen

    10.2.1 Beschreibung des Szenarios

    Mit der in Szenario 1 skizzierten Topologie kann auch ein Szenario bedient werden, bei dem mehrere Behandlungsräume unterstützt werden (siehe Abbildung 26). Dabei ist in jedem Behandlungsraum mindestens ein Kartenterminal vorzusehen, so dass die eGK gelesen werden kann.

    Auf die Darstellung der Kommunikationswege in zentrale Netze wurde in Abbildung 26 verzichtet, da sich hier keine Änderung gegenüber Szenario 1 ergibt.

    Durch die Ressourcenverwaltung des Konnektors wird sichergestellt, dass bei Anwendungsfällen diejenigen Kartenterminals angesprochen werden, welche dem Arbeitsplatz zugeordnet sind, von dem aus der Anwendungsfall initiiert wurde.

    10.2.2 Voraussetzungen

    10.2.3 Auswirkungen

    10.3 Szenario 3: Integration in bestehende Infrastruktur ohne Netzsegmentierung



    Abbildung 26: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur

    10.3.1 Beschreibung des Szenarios

    Im Falle einer bereits vorhandenen Infrastruktur im dezentralen Bereich können die Produkte der TI, insbesondere der Konnektor, so in die Infrastruktur integriert werden, dass Bestandsanwendungen bereits erprobte Kommunikationswege weiter nutzen können.

    Wie in Abbildung 27 beispielhaft dargestellt, existiert bereits eine Infrastruktur, die sowohl einen Internetzugang für die Arbeitsplätze ermöglicht (gestrichelte Linie in türkis), als auch eine Nebenstelle über VPN anbindet (gestrichelte Linie in blau). In diesem Fall wird der Konnektor als zusätzliches Gerät an das bestehende Netzwerk angeschlossen und nutzt den bereits vorhandenen Internetanschluss zur Kommunikation in die TI.

    Für die Clientsysteme muss in diesem Szenario je nach individuellem Anforderungsprofil entschieden werden, ob das jeweilige Clientsystem über die Telematikinfrastruktur kommunizieren können soll und den gesicherten Internetzugang (SIS) nutzen soll oder nicht.

    Soll ein Clientsysteme nicht über die Telematikinfrastruktur kommunizieren, bleibt der IAG als Default-Gateway dieses Clientsystems konfiguriert. In diesem Fall routet der IAG die eingehenden IP-Pakete mit öffentlichen Zieladressen weiter in das Internet. Die gestrichelte Linie in türkis zeigt beispielhaft einen Zugriff in das Internet.

    Soll ein Clientsystem über die Telematikinfrastruktur kommunizieren oder den gesicherten Internetzugang (SIS) nutzen, muss der Konnektor als Default-Gateway konfiguriert werden. In diesem Fall routet der Konnektor die eingehenden IP-Pakete, die nicht für ihn bestimmt sind, entweder durch den VPN-Tunnel der TI über die Telematikinfrastruktur in ein angeschlossenes Bestandsnetz, (gestrichelte Linie in rot) oder durch den VPN-Tunnel zum SIS (Secure Internet Service) in das Internet (gestrichelte Linie in grün). Sollte kein sicherer Internetzugang konfiguriert sein, so würde der Konnektor den Traffic verwerfen und ggf. per ICMP dem Client eine anderes Gateway (IAG) vorschlagen. Alternativ können die von den Clients benötigten Routing-Informationen manuell oder per DHCP konfiguriert werden.

    10.3.2 Voraussetzungen

    10.3.3 Auswirkungen

    10.4 Szenario 4: Integration in bestehende Infrastruktur mit Netzsegmentierung


    Abbildung 27: Szenario einer Integration der TI Produkte in eine bestehende Infrastruktur mit existierendem Router

    10.4.1 Beschreibung des Szenarios

    Das vorliegende Szenario skizziert eine etwas komplexere dezentrale Umgebung, in der das Netzwerk segmentiert ist und dedizierte Router als Default-Gateway für die Clientsysteme genutzt werden. In diesem Fall kann die Konfiguration der Clients unverändert bleiben und der Konnektor wird als zusätzliches Gerät in das Netzwerk integriert und dem Router bekanntgemacht als Gateway für den sicheren Internetzugang und den Zugang zu den an die Telematikinfrastruktur angeschlossenen Bestandsnetze.

    10.4.2 Voraussetzungen

    10.4.3 Auswirkungen

    10.5 Szenario 5: Zentral gesteckter HBA


    Abbildung 28: Szenario mit zentral gesteckten HBA und SMC-B

    10.5.1 Beschreibung des Szenarios

    Dieses Szenario zeichnet sich dadurch aus dass ein HBA nicht durch seinen Inhaber mitgeführt und am Arbeitsplatz gesteckt wird, sondern zentral und geschützt vor unbefugten physischen Zugriffen gesteckt bleibt.

    Der HBA-Inhaber greift über jeden konfigurierten Arbeitsplatz auf seinen HBA zu. Die Remote-PIN-Eingabe erfolgt unter Verwendung des lokal am Arbeitsplatz vorhandenen eHealth-Kartenterminals.

    Die Mechanismen zum Zugriff auf eine zentral gesteckte SMC-B funktionieren analog zum HBA.

    10.5.2 Voraussetzungen

    Folgende zusätzliche Punkte müssen erfüllt sein, um dieses Szenario umzusetzen:

    10.5.3 Auswirkung

    10.6 Szenario 6: Installation mit zentralem PS



    Abbildung 29: Szenario mit zentralem Primärsystem als Clientsystem

    10.6.1 Beschreibung des Szenarios

    Das Szenario skizziert eine dezentrale Konfiguration, bei der das Primärsystem aus einem Serveranteil „PS Server“ und mehreren Clientanteilen „PS Client“ besteht. Die Anbindung zwischen dem „PS Server“ und den „PS Clients“ ist herstellerspezifisch. Der „PS Server“ fungiert als ein einziges Clientsystem gegenüber der TI bzw. dem Konnektor (z.B. als Terminalserver). Die Clientsystemschnittstelle des Konnektors wird ausschließlich vom „PS Server“ genutzt. Der „PS Server“ muss bei der Kommunikation mit dem Konnektor eine Übersetzung der zugreifenden „PS Clients“ auf die entsprechende Entität „Arbeitsplatz“ des Konnektors durchführen

    Beispielhaft zeigt das Szenario zwei Arbeitsplätze mit jeweils einem Kartenterminal für die eGK sowie zentral gesteckte SMC-B und HBAs. Alternativ sind auch lokal am Arbeitsplatz gesteckte HBAs möglich.

    10.6.2 Voraussetzungen

    10.6.3 Auswirkungen

    10.7 Szenario 7: Mehrere Mandanten


    Abbildung 30: Szenario für den Zugriff

    10.7.1 Beschreibung des Szenarios

    Das Szenario skizziert eine dezentrale Konfiguration, bei der mehrere Mandanten vorhanden sind, wobei jedem Mandant eine eigene SMC-B zugeordnet ist. Die SMC-Bs sind zentral zusammen mit dem Konnektor geschützt vor unbefugten physischen Zugriffen installiert. Die Komponenten Arbeitplätze, Clientsysteme und Kartenterminals müssen eine Zuordnung zum Mandanten haben, wobei Zuordnungen zu mehreren Mandaten möglich sind. Das Beispiel zeigt einen Arbeitplatz mit „Clientsystem 1“ und „KT 1“, der zu unterschiedlichen Zeiten durch verschiedene Mandaten verwendet wird. Zum Zeitpunkt T=t1 greift ein Anwender 1 mit HBA 1 über einen Anwendungsfall im Kontext Mandat 1 auf die TI zu, wobei der Versicherte 1 mit eGK 1 am Anwendungsfall beteiligt ist. Zum Zeitpunkt T=t2 wird ein anderer Anwendungsfall im Kontext von Mandat 2 durch einen Anwender 2 ohne HBA initiiert, wobei der Versicherte 2 mit eGK 2 am Anwendungsfall beteiligt ist. Das Clientsystem stellt hierbei den Mandantenbezug sowie die Nutzer Authentisierung sicher. Als Variante können auch mehrere Mandanten eine Zuordnung zu einer einzelnen SMC-B haben. Weiterhin können auch in diesem Szenario HBAs zentral gesteckt werden.

    10.7.2 Voraussetzungen

    10.7.3 Auswirkungen

    10.8 Szenario 9: Standalone Konnektor - Physische Trennung


    Abbildung 31:  Standalone-Szenario mit physischer Trennung im Konnektor

    10.8.1 Beschreibung des Szenarios

    Dieses Szenario stellt eine Variante des Standalone-Szenarios dar, bei dem eine physische Trennung der Konnektoren eingesetzt wurde.

    Im Standalone-Szenario besteht eine Trennung zwischen den Praxissystemen der dezentralen Umgebung, welche offline (also, ohne Anbindung an die zentrale TI-Plattform) betrieben werden und den für das Update der eGK durch die Fachanwendung VSDM notwendigen Komponenten, welche online (also, mit Verbindung in die zentrale TI-Plattform) betrieben werden.

    Die physische Trennung im Standalone-Szenario zeichnet sich dadurch aus, dass getrennte Komponenten zum Einsatz kommen. Der Online-Konnektor ist mit der zentralen TI-Plattform verbunden und ermöglicht das VSDM Update der eGKs. Ein am Online-Konnektor angebundener Kommunikations-PC kann darüber hinaus über den sicheren Internetzugang der TI auf das Internet und über den VPN-Konzentrator TI auf Bestandsnetze zugreifen.

    Sollten die Online-/Offline-Systeme nicht netztechnisch voneinander getrennt sein, so obliegt es dem Administrator der Praxissysteme sicherzustellen, dass die netztechnische Verbindung keine Gefährdung für die Praxissysteme zur Folge hat.

    Im Offline-Konnektor sind einzelne Funktionen nicht verfügbar, andere haben einen eingeschränkten Funktionsumfang. So kann z.B. eine QES erzeugt oder geprüft aber dabei keine aktuelle Statusauskunft (OCSP-Response) für die eingesetzten Zertifikate eingeholt werden. Dies hat zur Folge, dass bei Erzeugung einer QES keine Statusauskunft für das Signaturzertifikat in die Signatur eingebettet werden kann und bei einer Prüfung der QES nur eine eventuell in die Signatur eingebettet Statusauskunft des Zertifikats berücksichtigt werden kann.

    Der Nutzer muss in diesem Fall selber entscheiden ob der gebotene Funktionsumfang für seinen Anwendungsfall ausreichend ist.

    10.8.2 Voraussetzungen

    Folgende zusätzliche Punkte müssen erfüllt sein, um dieses Szenario umzusetzen:

    10.8.3 Auswirkung

    11 Anhang L – Datentypen von Eingangs- und Ausgangsdaten

    Tabelle 397: Aufzähltypen

    Typname
    Werteliste
    [Boolean]
    {true | false}
    [EncryptionType]
    {CMS | XMLEnc | S/MIME}
    [EventType]
    {Op | Sec | Perf}
    [EventSeverity]
    {Debug | Info | Warn | Err | Fatal}
    [KtOutputMode]
    {Input | OutputWait | OutputConfirm | OutputKeep | OutputErase}
    [PinStatus]
    {VERIFIED | VERIFYABLE | BLOCKED | TRANSPORT_PIN | EMPTY_PIN | DISABLED}
    [PinResult]
    {OK | REJECTED | BLOCKED | ERROR}
    [PukResult]
    {OK | REJECTED | BLOCKED | ERROR}
    [VerificationResult]
    {VALID | INVALID | INCONCLUSIVE}